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前 


当前 网 络 正在 改变 人 们 生活 的 方方面面 ， 从 企业 内 部 的 管理 和 运营 到 我 们 个 人 的 吃 穿 住 行 ， 所 有 这 些 都 跟 网 络 有 着 密切 联系 。 不 过 这 一 切 才 刚刚 开始 ， 未 来 的 网 络 将 会 给 人 们 带 来 更 多 的 惊喜 ， 特 别 是 
在 2015 年 “两 会 ”中 将 “互联 网 +” 纳 入 我 国 的 发 展 战略 之 后 ， 网 络 未 来 几 年 的 高 速 发 展 更 会 超出 我 们 的 想象 。 


在 网 络 技术 中 基于 浏览 器 的 B/S 结构 无 论 在 PC 端 还 是 手机 端 都 充当 着 至 关 重 要 的 角色 。PC 端 自 不 必 说 ， 手 机 中 很 多 应 用 虽然 是 以 APP 的 形式 存在 ,但 它 采 用 的 还 是 B/S 结构 ， 如 今日 头条 、 微 信 的 朋友 图 
等 ， 这 些 应 用 在 内 部 封装 了 浏览 器 ， 后 端 仍然 是 Web 站 点 。 


在 大 型 网 站 和 复杂 系统 的 开发 中 ， Java 无疑 具有 很 大 的 优势 ， 而 在 Java 的 Web 框 架 中 SpringMVC 以 其 强大 的 功能 和 简单 且 灵 活 的 用 法 受到 越 来 越 多 开发 者 的 青睐。 


SpringMVC 入 门 很 简单 ， 但 是 要 想 真 正 使 用 好 却 并 非 易 事 ， 而 且 现 在 也 没有 全 面 、 深 入 的 使 用 资料 ， 以 致 在 实际 使 用 的 过 程 中 程序 员 经 常会 遇 到 各 种 各 样 的 问题 而 不 知道 如 何 解 决 。 对 Spring MVC 这 样 
的 开源 项 目 来 说 ， 最 好 的 学 习 方 法 当然 是 分 析 它 的 源 代码 ， 分 析 透 源 代码 不 仅 可 以 让 我 们 更 灵活 地 使 用 Spring MVC 来 开发 高 质量 的 产品 ， 而 且 可 以 学 习 到 其 中 的 很 多 优秀 的 编程 技巧 和 设计 理念 。 


本 书 除了 分 析 Spring MVC 的 源 代码 ， 还 系统 地 介绍 了 各 种 网 站 架构 的 演变 以 及 Web 开 发 中 所 涉及 的 协议 和 Tomcat 的 实现 方法 ， 现 在 很 多 程序 员 都 想 了 解 这 方面 的 知识 ， 但 车 于 缺乏 通俗 易 懂 的 资料 ， 而 
且 这 些 也 是 程序 员 达 到 更 高 的 层次 所 需要 的 知识 。 
通过 本 书 你 可 以 得 到 什么 

. 系统 学 习 网 站 的 各 种 架构 以 及 相应 问题 的 解决 方案 。 

. 零 基础 系统 学 习 Web 底 层 协议 及 其 实现 方法 。 

. 系统 、 深 入 地 理解 Spring MVC， 为 灵活 开发 高 质量 产品 打下 基础 。 

. 学 习 Spring MVC 的 编程 技巧 和 设计 理念 ， 提 高 自己 综合 思考 、 整 体 架构 的 能 力 。 

. 学 习 到 笔者 设计 的 一 套 分 析 源 码 的 方法 一 一 器 用 分 析 法 ， 古 人 说 “ 授 人 以 鱼 不 如 授 人 以 渔 ”， 虽 然 这 套 方法 并 不 复杂 但 是 对 于 分 析 复 杂 的 代码 却 非常 有 用 。 


当然 ， 并 不 是 说 像 看 小 说 一 样 翻 一 遍 本 书 就 可 以 获得 这 么 多 东西 ， 这 需要 大 家 真正 沉 下 心 来 认真 地 去 看 ， 而 且 最 好 能 对 照 着 源 代 码 去 看 。 俗 话说 “ 磨 刀 不 误 砍 柴 工 ”， 分 析 源 代 码 就 是 磨 刀 的 过 程 ， 是 
真正 提升 自己 实力 的 过 程 ， 就 像 武 术 里 的 内 功 修炼 一 样 ， 只 有 花 足 够 的 时 间 和 精力 才能 到 达 一 定 的 高 度 ， 这 就 是 我 们 经 常 说 的 “功夫 ”， 当 功夫 达到 一 定 的 高 度 时 很 多 琼 手 的 问题 就 可 以 轻而易举 地 解决 
TT 


本 书 读者 对 象 
" 有 Java 编 程 基 础 ， 想 学 习 JavaWeb 开 发 的 读者 。 
“ 有 JavaWeb 开 发 经 验 ， 想 学 习 Spring MVC 的 读者 。 
“ 有 基础 SpringMVC 开 发 经 验 ， 想 深入 学 习 的 读者 。 
“ 有 丰富 Spring MVC 开 发 经 验 ， 想 学 习 Spring MVC 底 层 代码 的 读者 。 


: 想 自己 开发 Spring MVC 插 件 的 读者 。 


本 书 特点 
:本 书 从 最 底层 的 架构 和 协议 开始 讲解 ， 即 使 没有 太 多 开发 经 验 的 读者 也 可 以 理解 ， 同 时 由 于 本 书包 含 的 内 容 全 面 而 且 深入 ， 所 以 即使 有 丰富 Web 开 发 经 验 的 读者 读 过 之 后 也 会 有 所 收获 。 


“ 本 书 采 用 了 总 分 总 的 结构 ， 首 先 概述 全 书 内 容 ， 让 大 家 在 脑子 里 建立 起 整个 框架 ， 然 后 再 对 每 个 点 展开 分 析 ， 最 后 总 结 。 这 就 好 像 一 栋 建 筑 ， 首 先 把 它 的 整体 结构 展示 给 大 家 ， 然 后 再 具体 介绍 每 个 
细节 ， 这 样 就 可 以 让 大 家 思路 清晰 而 不 至 于 迷失 方向 。 这 种 模式 最 符合 人 的 认 知 方式 ， 所 以 不 仅仅 适用 于 学 习 ， 而 且 可 以 使 用 到 别 的 很 多 地 方 ， 比 如 ， 进 入 一 个 新 公司 后 (特别 是 大 型 公司 ) ， 首 先 要 了 解 
一 下 公司 都 有 哪些 部 门 ， 各 个 部 门 之 间 是 怎么 协调 配合 的 ， 弄 明白 整体 结构 之 后 再 思考 自己 的 业务 ， 这 样 就 可 以 理解 得 更 加 深 ， 做 得 更 好 ， 如 果 有 机 会 再 多 了 解 点 其 他 部 门 的 业务 ， 这 样 成 长 得 就 会 更 快 。 


: 本 书 讲解 的 过 程 通俗 易 懂 、 深 入 浅 出 ， 对 于 不 容易 理解 的 内 容 ， 通 过 简单 的 例子 让 大 家 一 目 了 然 。 在 分 析 源 代码 的 过 程 中 还 对 一 些 代码 分 析 了 Spring MVC 为 什么 要 那么 处 理 ， 那 么 处 理 有 哪些 好 处 ， 


有 些 地 方 还 为 大 家 指出 了 需要 注意 的 问题 、 可 以 实现 的 需求 以 及 可 以 借鉴 的 东西 等 内 容 。 


本 书 结构 安排 
本 书 一 共 分 为 四 篇 。 


第 一 篇 首先 讲解 了 网 站 基础 知识 ， 包 括 网 站 架构 的 演变 以 及 每 种 架构 所 针对 的 问题 、Web 底 层 的 协议 以 及 简单 的 实现 方法 ， 最 后 分 析 了 Tomcat 的 实现 方法 ， 这 样 可 以 让 大 家 对 Web 有 整体 而 且 深 入 的 理 
解 ， 从 而 为 分 析 Spring MVC 打 下 坚实 的 基础 。 


第 二 篇 分 析 了 Spring MVC 的 整体 结构 ， 帮 助 大 家 理解 请 求 是 怎么 到 Spring MVC 中 的 ， 以 及 在 Spring MVC 中 都 做 了 些 什么 ， 这 部 分 主要 是 帮 大 家 建立 框架 ， 让 大 家 对 Spring MVC 的 整体 结构 了 然 于 胸 ， 在 后 
面 内 容 中 只 需要 对 具体 的 组 件 进行 分 析 即 可 。 


第 三 篇 分 别 对 Spring MVC 中 的 9 大 组 件 进行 了 分 析 ， 这 部 分 又 分 了 两 步 : 第 一 步 先 分 析 了 每 个 组 件 的 接口 、 作 用 和 用 法 ， 让 大 家 对 每 个 组 件 有 个 大 体 的 认识 ; 第 二 步 详 细 分 析 了 9 大 组 件 的 实现 。 


第 四 篇 对 Spring MVC 的 整体 结构 做 了 总 结 ， 并 对 异步 请 求 的 原理 及 用 法 做 了 补充 。 总 结 分 为 两 步 ， 首 先是 对 Spring MVC 的 结构 进行 总 结 ， 并 从 更 高 的 层次 分 析 其 设计 理念 ; 然后 通过 跟踪 一 个 具体 的 请 
求 帮 助 大 家 整体 梳理 请 求 的 处 理 过 程 。 异 步 请 求 是 一 块 相对 独立 的 内 容 ， 如 果 将 其 放 入 SpringMVC 的 分 析 过 程 中 将 增加 大 家 对 Spring MVC 的 理解 难度 ， 所 以 在 最 后 对 其 进行 单独 讲解 。 


本 书 源 代码 可 以 到 kantou.excelib.com/springmvc 下 载 。 
致谢 


我 最 想 感谢 的 就 是 我 的 父亲 韩 志 荣 ， 正 是 因为 他 的 大 力 支持 和 背后 的 默默 付出 才 让 笔者 可 以 将 更 多 的 时 间 和 精力 放 在 本 书 的 创作 上 ， 从 而 让 本 书 可 以 在 保证 质量 的 前 提 下 以 最 快 的 速度 跟 大 家 见面 。 


虽然 笔者 已 经 尽 了 自己 最 大 的 努力 ， 但 是 受 水 平 所 限 ， 难 免 会 有 遗漏 或 者 讲解 不 够 准确 的 地 方 ， 还 请 大 家 批评 指正 。 如 果 大 家 通过 本 书 可 以 对 Web 开 发 、 对 SpringMVC 的 理解 以 及 对 设计 的 理念 有 些许 
收获 ， 那 将 是 笔者 最 感到 欣慰 的 事情 。 


第 一 篇 ”网 站 基础 知识 


本 篇 主要 给 大 家 介绍 网 站 的 基础 知识 ， 为 后 面具 体 分 析 SpringMVC 打 下 基础 。 内 容 主要 包括 架构 的 演变 、Web 中 涉及 的 协议 、 协 议 的 实现 方法 、Java 中 的 Servlet 以 及 对 一 个 完整 的 产品 Tomcat 的 分 析 等 5 部 
分 。 

本 篇 的 很 多 内 容 ， 如 底层 协议 和 Tomcat 的 实现 方法 ， 在 正常 做 开发 的 时 候 并 不 会 直接 使 用 到 ， 不 过 理解 了 之 后 可 以 让 我 们 在 进行 具体 开发 的 时 候 更 加 得 心 应 手 ， 就 好 像 数 学 中 的 基本 运算 ， 我 们 不 需要 
知道 原理 也 可 以 借助 计算 器 计算 出 结果 ， 但 是 如 果 明 白 了 其 中 的 原理 就 可 以 对 计算 带 来 很 多 帮助 。 比 如 ， 可 以 预先 大 概 估计 计算 结果 ， 当 计算 器 的 计算 结果 偏差 很 大 时 就 可 以 看 出 来 ; 可 以 使 用 一 些 简单 的 
计算 方法 ; 还 可 以 通过 对 具体 内 容 的 学 习 学 到 一 些 优秀 思想 ， 思 想 本 身 是 很 难 学 习 的 ， 需 要 通过 一 定 的 载体 才 可 以 传播 ， 底 层 的 知识 就 是 这 样 的 载体 。 

现在 社会 中 普遍 注重 创新 ， 其 实 创新 是 建立 在 扎实 的 基础 之 上 的 ， 如 果 没有 扎实 的 基础 就 很 难 做 出 合理 而 且 易 用 的 创建 成 果 。 所 以 本 篇 的 内 容 虽 然 在 开发 中 一 般 不 会 直接 使 用 到 ， 但 是 对 于 提高 自己 的 
能 力 非 常 重要 。 


第 1 章 ”网 站 架构 及 其 演变 过 程 


本 章 介绍 网 站 的 架构 及 其 演变 的 过 程 。 现 在 大 型 网 站 的 架构 变 得 越 来 越 复杂 ， 不 过 架构 的 演变 过 程 并 不 是 没有 规律 的 ， 它 们 是 在 遇 到 相应 问题 之 后 为 了 解决 问题 才 演 变 出 来 的 。 本 章 首先 从 软件 的 三 大 
类 型 说 起 ， 然 后 介绍 各 种 架构 的 演变 过 程 及 其 背后 的 本 质 。 


1.1 软件 的 三 大 类 型 


记得 在 上 学 的 时 候 ， 计 算 机 考试 中 很 经 典 的 一 道 题 是 “ 开 电 脑 时 应 该 先 开 主 机 电源 还 是 先 开 显示 器 电源 ”， 那 个 时 代 的 软件 主要 以 单机 软件 为 主 ， 如 画图 板 、 五 笔 打 字 等 ， 当 时 学 习 使 用 电脑 跟 学 习 打 
字 基 本 上 是 一 个 概念 ， 那 些 不 需要 联网 的 单机 软件 就 是 最 开始 的 软件 。 


后 来 有 的 程序 需要 统一 管理 软件 中 使 用 的 数据 ， 所 以 就 将 保存 数据 的 数据 库 统一 存放 在 一 台 主机 中 ， 所 有 的 用 户 在 需要 数据 时 都 要 从 主机 获取 ， 这 时 就 分 出 了 客户 端 和 服务 端 ， 用 户 安装 的 软件 叫 客户 
端 (Client) ， 统 一 管理 数据 的 主机 中 的 软件 就 叫 服务 端 (Server) ， 这 种 结构 就 叫 CS 结构 。 再 后 来 这 种 结构 的 服务 端 就 不 只 是 管理 数据 了 ， 另 外 还 可 以 处 理 一 些 业务 逻辑 ， 哪 些 业务 放 到 客户 端 处 理 ， 哪 
些 业务 放 到 服务 端 处 理 就 是 见仁见智 的 问题 了 。 业 务 放 到 服务 端 统一 处 理 可 以 提供 更 好 的 安全 性 和 稳定 性 而 且 升 级 比较 容易 ， 不 过 服务 器 的 负担 就 增加 了 ; 业务 放 到 客户 端 处 理 可 以 将 负担 分 配 到 每 个 用 户 
的 机 器 上 ， 从 而 可 以 节省 服务 器 的 资源 ， 不 过 安全 性 和 稳定 性 可 能 会 有 一 些 问 题 ， 而 且 升 级 也 比较 麻烦 ， 每 个 用 户 安装 的 客户 端 程序 都 需要 升级 。 另 外 ， 为 了 节省 网 络 资源 ， 通 过 网 络 传输 的 数据 应 该 尽量 
少 。CS 结 构 如 图 1-1 所 示 。 


图 1-1 CS 结构 图 


CS 结构 的 程序 已 经 可 以 完成 网 络 通信 了 ， 不 过 使 用 起 来 还 是 有 点 麻烦 ， 首 先 软件 提供 商 需要 同时 开发 客户 端 和 服务 端 两 套 软 件 ， 其 次 每 个 用 户 在 使 用 时 都 需要 单独 安装 客户 端 软件 ， 而 且 升 级 的 时 候 也 
需要 每 个 用 户 都 进行 升级 。 为 了 解决 这 个 问题 而 设计 了 统一 的 客户 端 ， 而 且 默 认 安装 在 用 户 电脑 里 面 ， 这 就 是 我 们 电脑 中 的 浏览 器 (Browser) ， 而 且 一 个 浏览 器 可 以 访问 所 有 同 种 类 型 的 网 站 ， 当 然 它 主 
作 展 示 数 据 ， 具 体 业务 处 理 是 在 不 同 的 服务 端 进 行 的 ， 这 种 结构 就 叫 BS 结 构 。BS 结 构 除 了 提供 了 统一 的 客户 端 ， 还 根据 相应 协议 和 标准 提供 通用 的 服务 器 程序 ， 服 务 器 程序 统一 处 理 数据 连接 、 封 装 和 
解析 等 工作 。BS 结 构 如 图 1-2 所 示 。 


图 1-2 ”BS 结构 图 


这 就 是 软件 的 三 大 类 型 : 单机 类 型 、CS 类 型 和 BS 类 型 。 在 这 三 种 类 型 中 ， 因 为 BS 类 型 开发 简单 、 使 用 方便 而 且 功 能 强大 ， 所 以 现在 使 用 最 广 ， 当 然 并 不 是 说 BS 结构 是 最 好 的 ， 具 体 使 用 什么 结构 还 需 
要 根据 实际 的 需求 来 决定 ， 比 如 ， 现 在 我 们 电脑 中 的 记事 本 、Office 以 及 压缩 软件 等 都 是 单机 软件 ， 而 它们 使 用 得 也 非常 广泛 ， 另 外 BS 结构 虽然 比 CS 结 构 在 开发 和 使 用 上 都 简单 ， 但 是 BS 结构 的 灵活 性 和 处 
理 效率 都 不 如 CS 结构 ， 所 以 像 QQ、 大 型 游戏 等 软件 使 用 的 还 是 CS 结构 。 


1.2 ”基础 的 结构 并 不 简单 


前 面 介绍 的 BS 结 构 是 最 基础 的 结构 ， 不 过 即使 这 种 最 基础 的 结构 的 底层 实现 也 并 不 简单 ， 因 为 它 需要 通过 互联 网 传输 数据 ， 而 互联 网 是 一 个 错综复杂 的 网 络 ， 其 中 包含 的 节点 不 计 其 数 ， 而 且 每 两 个 节 
点 之 间 的 距离 以 及 连接 的 路 线 都 是 不 确定 的 ， 数 据 在 传输 的 过 程 中 还 可 能 会 丢失 ， 所 以 非常 复杂 。 所 有 问题 都 有 它 对 治 的 方法 ， 对 于 复杂 问题 的 对 治 方法 就 是 将 其 分 解 成 多 个 简单 的 问题 ， 然 后 通过 解决 每 
个 简单 问题 ， 最 终 解决 复杂 问题 。BS 结 构 网 络 传输 的 分 解 方式 有 两 种 : 一 种 是 标准 的 OSI 参考 模型 ， 另 一 种 是 TCP/IP 参 考 模型 。 它 们 的 分 层 方式 及 对 应 关系 如 图 1-3 所 示 。 


OSI 参考 模型 TCP/P 参 考 模型 


应 用 技 


会 十 压 


传输 


网 际 互联 层 


数据 链 路 层 
物理 层 


网 络 接 入 层 


图 1-3 ”OSI 和 TCP/IP 分 层 模 型 及 对 应 关系 


OSI 参 考 模型 一 共 分 7 层 ， 不 过 它 主要 用 于 教学 ， 实 际 使 用 中 更 多 的 是 TCP/IP 的 4 层 模型 。 对 于 TCP/IP 的 4 层 模型 可 以 简单 地 理解 为 : 


“ 网 络 接 入 层 : 将 需要 相互 连接 的 节点 接 入 网 络 中 ， 从 而 为 数据 传输 提供 条 件 。 
“ 网 际 互联 层 : 找到 要 传输 数据 的 目标 节点 。 
“ 传输 层 : 实际 传输 数据 。 


“应 用 层 : 使 用 接收 到 的 数据 。 


这 种 分 层 模 型 非常 容易 理解 ， 就 好 像 我 们 要 在 网 上 买 东西 ， 首 先 要 确定 自己 所 在 的 位 置 有 相应 的 快递 ， 这 就 相当 于 网 络 接 入 层 ， 然 后 需要 告诉 卖家 地 址 ， 地 址 就 相当 于 网 际 互联 层 ， 快 递送 货 相 当 于 传 
输 层 ， 最 后 我 们 收 到 货物 之 后 拆 包 使 用 就 相当 于 应 用 层 。 


对 于 广泛 使 用 的 东西 就 需要 制定 相应 的 标准 ， 没 有 规矩 不 成 方圆， 如 果 都 按 自己 的 想法 去 做 就 乱 套 了 。 对 一 个 小 作坊 来 说 ， 做 事情 可 以 比较 随意 ， 但 是 一 个 大 型 公司 就 需要 有 很 多 制度 来 规范 做 事情 的 
流程 了 。 由 于 网 络 传输 应 用 非常 广泛 ， 所 以 需要 大 家 都 遵守 的 规矩 ， 不 过 网 络 传输 中 的 这 些 规矩 并 不 是 强制 性 的 ， 所 以 不 叫 制度 也 不 叫 标准 而 叫 协议 ， 其 实 TCP/IP 参 考 模型 也 可 以 看 作 一 种 协议 。BS 结 构 中 
TCP/IP 模 型 中 的 网 络 接 入 层 没有 相应 协议 ， 网 际 互联 层 是 IP 协 议 ， 传 输 层 是 TCP 协 议 ， 应 用 层 是 HTTP 协 议 。 


另外 在 BS 结 构 中 还 使 用 到 了 DNS 协议 ， 而 且 在 HTTP 上 层 还 有 相关 的 规范 ， 如 Java Web 开 发 中 使 用 的 是 Servlet 标 准 。 


数据 传输 的 本 质 就 是 按照 晶振 震动 周期 或 者 其 整数 倍 来 传输 代表 0/1 的 高 低 电 平 ， 传 输 过 程 中 最 核心 就 是 各 种 传输 协议 ， 对 直接 连接 的 硬件 来 说 就 是 各 种 总 线 协议 ， 对 网 络 传输 来 说 就 是 网 络 协议 ， 如 果 
将 传输 的 协议 弄 明白 了 ， 那 么 也 就 掌握 了 传输 的 核心 ， 第 2 章 会 介绍 BS 结构 中 常用 的 协议 和 标准 。 下 面 先 接着 看 网 站 架构 的 演变 过 程 ， 开 发 一 套 前 面 介绍 的 那 种 BS 结构 的 程序 并 非 难事 ， 特 别 是 使 用 现在 成 
形 的 框架 来 做 就 更 加 简单 了 ， 只 需要 写 好 核心 的 业务 就 可 以 了 。 不 过 这 种 基础 架构 的 网 站 虽然 可 以 用 但 并 不 代表 好 用 ， 除 了 用 户 交 互 ( 那 是 另外 一 个 话题 ) ， 最 重要 的 就 是 速度 问题 。 如 果 打开 一 个 连接 的 
时 间 都 可 以 喝 完 一 杯 咖啡 那样 的 系统 能 不 能 使 用 就 看 每 个 人 自己 的 理解 了 。 不 过 无 论 怎 么 理解 ， 如 果 不 是 企业 内 部 办 公 必 须 使 用 的 系统 ， 也 不 是 像 12306 那 种 具有 芍 断 资源 的 系统 ， 相 信 大 部 分 人 是 不 会 
有 那个 耐心 去 等 待 的。 解决 速度 问题 的 核心 主要 就 是 解决 海量 数据 操作 问题 和 高 并 发 问题 ， 网 站 复杂 的 架构 就 是 从 这 两 个 问题 演变 出 来 的 。 


1.3 ”架构 演变 的 起 点 


基础 架构 中 服务 端 就 一 台 主机 ， 其 中 存储 了 应 用 程序 和 数据 库 ， 刚 上 线 时 是 没有 问题 的 ， 当 数据 和 流量 变 得 越 来 越 大 的 时 候 就 难以 应 付 了 ， 这 时 候 就 需要 将 应 用 程序 和 数据 库 分 别 放 到 不 同 的 主机 中 ， 
其 结构 如 图 1-4 所 示 。 


应 用 服务 器 


互联 网 


图 1-4 应 用 和 数据 分 离 结构 图 


1.4 海量 数据 的 解决 方案 


现在 无 论 是 企业 的 业务 系统 还 是 互联 网 上 的 网 站 程序 都 面临 着 数据 量 大 的 问题 ， 这 个 问题 如 果 解 决 不 好 将 严重 影响 系统 的 运行 速度 ， 下 面 就 针对 这 个 问题 的 各 种 解决 方案 进行 系统 介绍 。 


1.4.1 ”缓存 和 页 面 静态 化 


数据 量 大 这 个 问题 最 直接 的 解决 方案 就 是 使 用 缓存 ， 缓 存 就 是 将 从 数据 库 中 获取 的 结果 暂时 保存 起 来 ， 在 下 次 使 用 的 时 候 无 需 重新 到 数据 库 中 获取 ， 这 样 可 以 大 大 降低 数据 库 的 压力 。 


缓存 的 使 用 方式 可 以 分 为 通过 程序 直接 保存 到 内 存 中 和 使 用 缓存 框架 两 种 方式 。 程 序 直接 操作 主要 是 使 用 Map， 尤 其 是 ConcurrentHashMap， 而 常用 的 缓存 框架 有 Ehcache、Memcache 和 Redis 
竺 。 缓 存 使 用 过 程 中 最 重要 问题 是 什么 时 候 创建 缓存 和 缓存 的 失效 机 制 。 缓 存 可 以 在 第 一 次 获取 的 时 候 创建 也 可 以 在 程序 启动 和 缓存 失效 之 后 立即 创建 ， 缓 存 的 失效 可 以 定期 失效 ， 也 可 以 在 数据 发 生变 化 
的 时 候 失 效 ， 如 果 按 数据 发 生变 化 让 缓存 失效 ， 还 可 以 分 粗 粒度 失效 和 细 粒 度 失效 。 


多 知道 点 


缓存 中 空 数据 的 管理 方法 
如 果 缓 存 是 在 第 一 次 获取 的 时 候 创建 的 ， 那 么 在 使 用 缓存 的 时 候 最 好 将 没有 数据 的 缓存 使 用 特定 的 类 型 值 来 保存 ， 因 为 这 种 方式 下 如 果 从 缓存 中 获取 不 到 数据 就 会 从 数据 库 中 获取 ， 如 果 数据 库 中 本 来 
就 没有 相应 的 数据 就 不 会 创建 缓存 ， 这 样 将 每 次 都 会 查询 数据 库 。 比 如 有 个 专门 保存 文章 评论 的 缓存 ， 不 同 的 评论 按照 不 同文 章 的 Id 来 保存 ， 如 果 有 一 篇 文章 本 来 就 没有 评论 ， 那 么 就 没有 相应 的 缓存 或 者 
缓存 的 值 为 mull， 这 样 程序 在 每 次 调用 这 篇 文章 的 评论 时 都 会 查询 数据 库 。 这 就 没 起 到 缓存 的 作用 ， 我 们 可 以 创建 一 个 专门 的 类 (如 NoComment) 来 保存 没有 评论 的 缓存 ， 这 样 程序 从 缓存 中 查询 后 就 可 以 知 
道 是 还 没有 创建 缓存 还 是 本 来 就 没有 评论 内 容 。 


不 过 缓存 也 不 是 什么 情况 都 适用 ， 它 主要 用 于 数据 变化 不 是 很 频繁 的 情况 。 而 且 如 果 是 定期 失效 (数据 修改 时 不 失效 ) 的 失效 机 制 ， 实 时 性 要 求 也 不 能 太 高 ， 因 为 这 样 缓存 中 的 数据 和 真实 数据 可 能 会 
不 一 致 。 如 果 是 文章 的 评论 则 关系 不 是 很 大 ， 但 如 果 是 企业 业务 系统 中 要 生成 报表 的 数据 则 问题 就 大 了 。 


跟 缓存 相似 的 另外 一 种 技术 叫 页 面 静态 化 ， 它 在 原理 上 跟 缓 存 非常 相似 ， 缓 存 是 将 从 数据 库 中 获取 到 的 数据 (当然 也 可 以 是 别 的 任何 可 以 序列 化 的 东西 ) 保存 起 来 ， 而 页 面 静态 化 是 将 程序 最 后 生成 的 
页 面 保存 起 来 ， 使 用 页 面 静态 化 后 就 不 需要 每 次 调用 都 重新 生成 页 面 了 ， 这 样 不 但 不 需要 查询 数据 库 ， 而 且 连 应 用 程序 处 理 都 省 了 ， 所 以 页 面 静态 化 同时 对 数据 量 大 和 并 发 量 高 两 大 问题 都 有 好 处 。 


页 面 静态 化 可 以 在 程序 中 使 用 模板 技术 生成 ， 如 常用 的 Freemarker 和 Velocity 都 可 以 根据 模板 生成 静态 页 面 ， 另 外 也 可 以 使 用 缓存 服务 器 在 应 用 服务 器 的 上 一 层 缓存 生成 的 页 面 ， 如 可 以 使 用 Squid， 
另外 Nginx 也 提供 了 相应 的 功能 。 


1.4.2 数据库 优 化 


要 解决 数据 量 大 的 问题 ， 是 避 不 开 数 据 库 优化 的 。 数 据 库 优化 可 以 在 不 增加 硬件 的 情况 下 提高 处 理 效率 ， 这 是 一 种 用 技术 换 金 钱 的 方式 。 数 据 库 优化 的 方法 非常 多 ， 常 用 的 有 表 结 构 优 化 、SQL 语 句 优 
化 、 分 区 和 分 表 、 索 引 优 化 、 使 用 存储 过 程 代替 直接 操作 等 ， 另 外 有 时 候 合理 使 用 匈 余 也 能 获得 非常 好 的 效果 。 


表 结 构 优化 


lel 


的 性 能 问题 ， 具 体 怎么 设计 更 合理 也 没有 固定 不 变 的 准则 ， 需 要 根据 实际 情况 具体 处 理 。 


表 结 构 优化 是 数据 库 中 最 基础 也 是 最 重要 的 ， 如 果 表 结构 优化 得 不 合理 ， 就 可 能 导致 严 


SQL 语 句 优化 


SQL 语 句 优化 也 是 非常 重要 的 ， 基 础 的 SQL 优 化 是 语法 层面 的 优化 ， 不 过 更 重要 的 是 处 理 逻 辑 的 优化 ， 这 也 需要 根据 实际 情况 具体 处 理 ， 而 且 要 和 索引 缓存 等 配合 使 用 。 不 过 SQL 优 化 有 一 个 通用 的 做 法 
就 是 ， 首 先 要 将 涉及 大 数据 的 业务 的 SQL 语句 执行 时 间 详 细 记 录 下 来 ， 其 次 通过 仔细 分 析 日 志 (同一 条 语句 对 不 同 条 件 的 执行 时 间 也 可 能 不 同 ， 这 点 也 需要 仔细 分 析 ) 找 出 需要 优化 的 语句 和 其 中 的 问题 ， 
然后 再 有 的 放 矢 地 优化 ， 而 不 是 不 分 重点 对 每 条 语句 都 花 同样 的 时 间 和 精力 优化 。 


分 


区 


当 数 据 量变 多 的 时 候 ， 如 果 可 以 分 


区 或 者 分 表 ， 那 将 起 到 非常 好 的 


效果 。 当 一 张 表 中 的 数据 量变 多 的 时 候 操作 速度 就 慢 了 ， 所 以 很 容易 想到 的 就 是 将 数据 分 到 多 个 表 中 保存 


， 但 是 这 么 做 之 后 操作 起 来 


比较 麻烦 ， 想 操作 (增删 改 查 ) 一 个 数据 还 需要 先 找 到 对 应 的 表 ， 如 果 涉 及 多 个 表 还 得 跨 表 操作 。 其 实在 常 


的 数 


照 一 定 的 规则 分 到 不 同 的 区 来 保存 ， 这 样 在 查询 数据 时 如 果 数 据 的 范围 在 同一 个 区 内 那么 可 以 只 对 一 个 
做 任何 改动 。 
分 表 


如 果 一 张 表 中 的 数据 可 以 分 为 几 种 固 


届 库 中 可 以 不 分 表 而 达到 跟 分 表 类 似 的 效果 ， 那 就 是 分 
区 的 数据 进行 操作 ， 这 样 操 作 的 数据 量 更 少 ， 


区 。 分 


区 就 是 将 一 张 表 中 的 数据 按 


速度 更 快 ， 而 且 这 种 方法 对 程序 是 透明 的 ， 程 序 不 需要 


定 不 变 的 类 型 ， 而 且 如 果 同 时 对 多 种 类 型 共同 操作 的 情况 不 多 ， 那 么 都 可 以 通过 分 表 来 处 理 ， 这 也 需 


时 就 将 其 中 保存 工人 工作 卡片 的 数据 表 分 成 了 三 个 表 ， 并 且 对 每 个 表 进行 分 


分 


区 是 按 月 份 来 分 的 ， 每 个 月 一 个 分 


区 ， 在 同时 使 
在 工段 及 班组 等 信息 ) 、 索 引 、SQL 优 化 等 的 情况 下 操作 速度 比 原来 提高 了 100 倍 以 上 。 局 
要 保存 是 谁 在 什么 时 候 对 卡片 进行 修改 ,修改 前 的 数据 是 什么 ， 添 加 删除 也 一 样 ， 这 种 需求 一 般 的 做 法 就 是 
将 卡片 分 别 保存 到 了 三 个 表 中 ， 第 一 个 表 保存 正常 卡片 ， 第 二 个 表 保 存 删除 后 的 卡片 ， 第 三 个 表 保存 修改 之 前 的 卡片 ， 并 且 对 每 个 表 都 进行 了 分 
区 ， 这 样 问题 就 解决 了 。 当 然 随 着 时 间 的 推移 ， 如 果 总 数据 量 达到 一 定 程度 ， 还 需要 进一步 处 理 。 


缓存 ( 主 


了 时 的 分 表 是 按照 工作 卡片 的 类 型 来 划分 的 ， 


一 


体 情况 具 


体 对 待 。 笔 者 之 前 对 一 个 业务 系统 进行 重 构 开 发 
于 在 保存 和 修改 时 对 其 他 表 的 数据 获取 中 ， 如 根据 工人 Id 获取 工人 姓名 、 工 人 类 别 、 所 在 单位 、 所 
因为 当时 的 要 求 是 要 保留 所 有 的 记录 。 比 如 ,修改 了 卡片 的 信息 ， 则 需 
一 个 字段 来 做 卡片 状态 的 标志 位 ， 将 卡片 分 成 不 同 的 类 型 。 不 过 这 里 由 


于 数据 量 非常 大 所 以 就 


另外 一 种 分 表 的 方法 是 将 一 个 表 中 不 同类 型 的 字段 分 到 不 同 的 表 中 保存 ， 这 么 做 最 直 


接 的 


好 处 就 是 增删 改 数据 的 时 候 锁定 的 范围 


， 在 增删 改 其 中 一 部 分 字段 数据 的 
范围 。 不 过 这 样 分 表 之 后 ， 如 果 需 要 查询 完整 的 数据 就 得 使 


囊 


多 表 操作 了 。 


放 


索引 优化 


增 
目 


索引 的 大 致 原理 是 在 数据 发 生变 化 〈 


同时 另 一 部 分 字段 也 可 能 被 操作 ， 而 且 (主要 指 查询 ) 


j 改 ) 的 时 候 就 预先 按 指定 字段 的 顺序 排列 


后 保存 到 一 个 类 似 表 的 结构 中 ， 这 样 在 查找 索引 字段 为 条 件 的 记录 时 就 可 以 很 快 地 从 索引 


表 中 获取 到 记录 ， 这 样 速 度 就 快 多 了 。 不 过 索引 也 是 一 把 双 刃 剑 ， 它 在 提高 查询 速度 的 


品 


时 也 降低 了 增删 改 的 速度 ， 


非常 明显 ， 所 以 对 哪些 字段 使 


索引 、 使 用 什么 类 型 的 索引 都 需要 仔细 琢 


使 


用 存储 过 程 代 蔡 直 接 操作 


磨 ， 并 且 最 好 和 


做 一 些 测试 。 


区 。 由 于 报表 一 般 是 按 月 份 、 季 度 、 半 


因为 每 次 数据 的 变化 都 需 


更 新 相应 的 索引 。 不 过 合理 使 


和 年 来 做 的 ， 所 以 


减 小 了 ， 没 被 锁定 的 表 中 的 数据 不 受 影响 。 如 果 一 个 表 的 操作 频率 很 
不 到 被 增删 改 的 字段 ， 那 么 就 可 以 把 不 同类 型 的 字段 分 别 保存 到 不 同 的 表 中 ， 这 样 可 以 减少 操作 时 锁定 数据 的 


中 找到 对 应 记录 的 指针 并 从 
索引 对 提升 查询 速度 的 效果 


在 操作 过 程 


杂 而 且 调 


频率 高 的 业务 中 ， 可 以 通过 使 


存储 过 程 代 蔡 直 接 操作 来 提高 效率 ， 


上 


面 这 些 就 是 经 党 


到 的 


数据 库 优 化 的 方法 ， 实 际 环境 中 怎么 优化 还 得 具 


体 情况 具 


1.4.3 “分离 活跃 数据 


不 多 ， 而 不 活跃 的 用 户 中 有 的 偶尔 也 会 登录 网 站 ， 
中 查找 ， 如 果 找 不 到 再 从 不 活跃 


虽然 有 些 数据 总 数据 量 非常 大 ， 但 是 活跃 数据 并 不 多 ， 这 种 情况 就 可 以 将 活跃 数据 和 
此 还 不 能 删除 。 这 时 就 可 以 通过 一 个 定期 处 理 的 任务 将 不 活跃 的 
户 表 中 查找 ， 这 样 就 可 以 提高 查询 的 效率 。 判 断 活 跃 


站 独 保存 起 来 从 而 提高 处 理 效率 。 比 如 ， 对 网 站 来 说 ， 


因为 存储 过 程 只 需要 编译 一 次 ， 而 且 可 以 在 一 个 存储 过 程 里 


体 分 析 。 除 了 这 些 优化 方法 ， 更 重要 的 是 业务 逻辑 的 优化 。 


户 很 多 时 候 就 是 这 种 数据 ， 注 册 


面 做 一 些 复杂 的 操作 。 


户 很 多 ， 但 是 活跃 用 户 却 


户 转移 到 别 的 数据 表 中 ， 在 3 


户 可 以 通过 最 近 登 录 时 间 ， 


上 的 文章 (特别 是 新 闻 类 的 ) 、 企 业 业 务 系统 中 按时 间 记 录 的 数据 等 。 


1.4.4 ”批量 读 取 和 延迟 修改 


批量 读 取 和 延迟 修改 的 原理 是 通过 减少 操作 的 次 数 来 提高 效率 ， 如 果 使 


但 | 
集 I 己 ， 


效率 将 会 呈 数 量 级 提升 。 


批量 读 取 是 将 多 次 查询 合并 到 一 次 中 进行 ， 比 如 


， 在 一 个 业务 系统 中 需要 批量 导入 工人 信息 ， 在 导入 前 需 


在 ) 、 工 人 的 工种 信息 在 工种 表 中 是 否 存 在 等 ， 如 果 每 保存 一 条 记录 都 查询 一 次 数据 库 ， 


检查 工人 的 编码 是 否 已 经 在 数 拉 


要 操作 的 数据 表 中 只 保存 活跃 


户 ， 查 询 时 先 从 默认 表 


也 可 以 通过 指定 时 间 段 内 登录 次 数 。 除 了 


习 


的 相应 字段 读 取 到 一 个 变量 中 ， 然 后 使 用 in 语句 统一 查询 一 次 数 
多 个 请 求 的 查询 合并 到 一 次 进行 ， 如 将 3 秘 或 5 秒 内 的 


居 库 ， 这 样 就 可 以 将 n 


延迟 修改 主要 针对 高 并 发 而 且 频 繁 修改 (包括 新 增 ) 的 数据 ， 如 一 些 统计 数据 。 这 种 情况 可 以 先 将 需要 修改 的 数据 暂时 保存 到 缓存 中 ， 然 


所 有 请 求 合并 到 一 起 统一 查询 一 次 数 拉 


p 么 对 每 个 需要 检查 的 字段 ， 都 需 


保存 记录 的 条 数 ) 次 查询 变 为 一 次 查询 了 。 除 了 这 和 


( 


以 同时 读 取 数 据 库 中 和 缓存 中 的 数据 。 这 里 的 缓存 和 前 面 介绍 的 缓存 有 本 质 的 区 别 ， 前 面 的 缓存 在 使 
如 果 保存 缓存 的 机 器 出 现 了 问题 将 可 能 会 丢失 数据 ， 所 以 如 果 是 重要 的 数据 就 需要 做 一 些 特殊 处 理 。 笔 者 之 前 所 在 的 自 


就 处 于 基本 瘫痪 的 状态 了 ， 而 且 各 厂 从 整理 出 数据 到 


1.4.5 ” 读 写 分 离 


读 写 分 离 的 本 质 是 对 数据 库 进 行 集群 ， 这 样 就 可 以 在 高 并 发 的 情况 下 将 数据 库 的 操作 分 配 到 多 个 数据 库 服务 器 去 处 理 从 而 降低 和 
据 都 需要 一 致 ， 所 以 数据 同步 就 成 了 数据 库 集群 中 最 核心 的 问题 。 如 果 多 台 服 务 器 都 可 以 写 数据 那么 数据 同步 
层 同步 到 别 的 服务 器 (从 服务 器 ) ， 读 数据 的 时 候 到 从 服务 器 读 取 ， 从 服务 器 可 以 有 多 人 台 ， 
服务 器 先 向 其 中 一 部 分 从 服务 器 同步 数据 ， 第 一 部 分 从 服务 器 接收 到 数据 


服务 器 叫做 主 服务 器 。 当 主 服务 器 写 入 (增删 改 ) 数据 后 从 底 
个 服务 器 处 理 。 主 服务 器 向 从 服务 器 同步 数据 时 ， 如 果 从 服务 器 数量 多 ， 那 么 可 以 让 3 
所 示 。 


导入 系统 只 有 几 天 的 时 间 ， 所 以 有 的 厂 就 专门 等 


居 库 ， 这 样 就 可 以 有 效 减 少 查询 数据 库 的 次 数 ， 这 种 


过 程 中 ， 数 据 库 中 的 数据 一 直 


得 
变 得 


查询 与 要 保存 的 记录 条 数 相 


步 请 求 来 处 理 。 


是 最 完整 的 ， 但 这 和 


位 有 一 个 系统 需要 每 月 月 末 各 厂 分 别 导入 


户外 还 有 很 多 这 种 类 型 的 数据 ， 如 一 个 网 站 


居 库 中 、 工 人 对 应 的 部 门 信息 是 否 正 确 (在 部 门 表 中 是 否 存 
同 次 数 的 数据 库 ， 这 时 可 以 先 将 所 有 要 保存 的 数据 
对 同一 个 请 求 中 的 数据 批量 读 取 ， 在 高 并 发 的 情况 下 还 可 以 将 
类 型 可 以 


后 定时 将 缓存 中 的 数据 保存 到 数据 库 中 ， 程 序 在 读 取 数 据 时 可 
数据 库 中 的 数据 会 有 一 段 时 间 不 完整 。 这 种 方式 下 
己 厂 当 月 的 相应 数据 ， 每 到 月 末 那 个 系统 


晚上 人 少 的 时 候 才 进 行 操作 ， 对 于 这 种 情况 就 可 采 


延迟 修改 的 策略 来 解决 


a 台 服 务 器 的 压力 ， 不 过 由 于 数据 库 的 特殊 性 一 每 台 服 务 器 所 保存 的 数 
非常 复杂 ， 所 以 一 般 情况 下 是 将 写 操作 交 给 专门 的 一 台 服 务 器 处 理 ， 这 台 专 门 负责 写 的 


这 样 就 可 以 实现 读 写 分 离 ， 并 且 将 读 请 求 分 配 到 


多 


后 再 向 另外 一 部 分 同步 ， 这 时 的 结构 如 


图 


1-5 


应 用 服务 天 


互联 网 
浏览 器 一 


图 1-5 ”数据 库 读 写 分 离 结 构 


简单 的 数据 同步 方式 可 以 采用 数据 库 的 热 备 份 功能 ， 不 过 读 取 到 的 数据 可 能 会 存在 一 定 的 滞后 性 ， 高 级 的 方式 需要 使 用 专门 的 软 硬 件 配合 。 另 外 既然 是 集群 就 涉及 负载 均衡 问题 ， 负 载 均衡 和 读 写 分 离 
的 操作 一 般 采 用 专门 程序 处 理 ， 而 且 对 应 用 系统 来 说 是 透明 的 。 


1.4.6 “分 布 式 数 据 库 


分 布 式 数据 库 是 将 不 同 的 表 存放 到 不 同 的 数据 库 中 然后 再 放 到 不 同 的 服务 器 。 这 样 在 处 理 请 求 时 ， 如 果 需 要 调用 多 个 表 ， 则 可 以 让 多 人 台 服 务 器 同时 处 理 ， 从 而 提高 处 理 速 度 。 


数据 库 集群 ( 读 写 分 离 ) 的 作用 是 将 多 个 请 求 分 配 到 不 同 的 服务 器 处 理 ， 从 而 减轻 单 台 服务 器 的 压力 ， 而 分 布 式 数据 库 是 解决 单个 请 求 本 身 就 非常 复杂 的 问题 ， 它 可 以 将 单个 请 求 分 配 到 多 个 服务 器 处 
理 ， 使 用 分 布 式 后 的 每 个 节点 还 可 以 同时 使 用 读 写 分 离 ， 从 而 组 成 多 个 节点 群 ， 结 构图 如 图 1-6 所 示 。 


数据 库 分 布 式 节点 群 1 


数据 库 分 布 式 节 点 和 群 2 


图 1-6 ”分 布 式 数据 库 架构 


实际 使 用 中 分 布 式 数据 库 有 很 多 复杂 的 问题 需要 解决 ， 如 事务 处 理 、 多 表 查 询 等 。 分 布 式 的 另外 一 种 使 用 的 思路 是 将 不 同业 务 的 数据 表 保存 到 不 同 的 节点 ， 让 不 同 的 业务 调用 不 同 的 数据 库 ， 这 种 用 法 
其 实 是 和 集群 一 样 起 分 流 的 作用 ， 不 过 这 种 情况 就 不 需要 同步 数据 了 。 使 用 后 面 这 种 思路 时 架构 还 是 和 上 面 图 中 的 一 样 ， 所 以 技术 和 架构 只 是 一 个 工具 ， 真 正 重要 的 是 思路 ， 也 就 是 工具 的 使 用 方法 。 


1.4.7 NoSQL 和 Hadoop 


NoSQL 是 近年 来 发 展 非常 迅速 的 一 项 技术 ， 它 的 核心 就 是 非 结构 化 。 我 们 一 般 使 用 的 数据 库 (SQL 数 据 库 ) 都 是 需要 先 将 表 的 结构 定义 出 来 ， 一 个 表 有 几 个 字段 ， 每 个 字段 各 是 什么 类 型 ， 然 后 才能 往 
里 面 按照 相应 的 类 型 保存 数据 ， 而 且 按 照 数据 库 范式 的 规定 ， 一 个 字段 只 能 保存 单一 的 信息 ， 不 可 以 包括 多 层 内 容 ， 这 就 对 使 用 的 灵活 性 带 来 了 很 大 的 制约 ，NoSQL 就 是 突破 了 这 些 条 条 框框 ， 可 以 非常 灵 
活 地 进行 操作 ， 另 外 因为 NoSQL 通 过 多 个 块 存储 数据 的 特点 ， 其 操作 大 数据 的 速度 也 非常 快 ， 这 些 特性 正 是 现在 的 互联 网 程序 最 需要 的 ， 所 以 NoSQL 发 展 得 非常 快 。 现 在 NoSQL 主 要 使 用 在 互联 网 的 程序 
中 ， 在 企业 业务 系统 中 使 用 的 还 不 多 ， 而 且 现 在 NoSQL 还 不 是 很 成 熟 ， 但 由 于 灵活 和 高 效 的 特性 ，NoSQL 发 展 的 前 景 是 非常 好 的 。 


Hadoop 是 专门 针对 大 数据 处 理 的 一 套 框架 ， 随 着 近年 来 大 数据 的 流行 Hadoop 也 水 涨 船 高 ， 出 世 不 久 就 红 得 发 紫 。Hadoop 对 数据 的 存储 和 处 理 都 提供 了 相应 的 解决 方案 ， 底 层 数据 的 存储 思路 类 似 于 
1.4.6 节 介绍 的 分 布 式 加 集群 的 方案 ， 不 过 Hadoop 是 将 同一 个 表 中 的 数据 分 成 多 块 保存 到 多 个 节点 (分 布 式 ) ， 而 且 每 一 块 数据 都 有 多 个 节点 保存 (集群 ) ， 这 里 集群 除了 可 以 并 行 处 理 相同 的 数据 ， 还 可 
以 保证 数据 的 稳定 性 ， 在 其 中 一 个 节点 出 现 问题 后 数据 不 会 丢失 。 这 里 的 每 个 节点 都 不 包含 一 个 完整 的 表 的 数据 ， 但 是 一 个 节点 可 以 保存 多 个 表 的 数据 ， 结 构图 如 图 1-7 所 示 。 


据 块 3 数据 块 1 | | 数据 块 2 | | 数据 块 3 


图 1-7 Hadoop 数 据 存储 结构 图 


Hadoop 对 数据 的 处 理 是 先 对 每 一 块 的 数据 找到 相应 的 节点 并 进行 处 理 ， 然 后 再 对 每 一 个 处 理 的 结果 进行 处 理 ， 最 后 生成 最 终 的 结果 。 比 如 ， 要 查找 符合 条 件 的 记录 ，Hadoop 的 处 理 方式 是 先 找 到 每 一 
块 中 符合 条 件 的 记录 ， 然 后 再 将 所 有 获取 到 的 结果 合并 到 一 起 ， 这 样 就 可 以 将 同一 个 查询 分 到 多 个 服务 器 处 理 ， 处 理 的 速度 也 就 快 了 ， 这 一 点 传统 的 数据 库 是 做 不 到 的 。 


1.5 “高 并 发 的 解决 方案 
除了 数据 量 大 ， 另 一 个 常见 的 问题 就 是 并 发 量 高 ， 很 多 架构 就 是 针对 这 个 问题 设计 出 来 的 ， 下 面 分 别 介绍 。 


1.5.1 ”应 用 和 静态 资源 分 离 


刚 开始 的 时 候 应 用 和 静态 资源 是 保存 在 一 起 的 ， 当 并 发 量 达到 一 定 程度 时 就 需要 将 静态 资源 保存 到 专门 的 服务 器 中 ， 静 态 资源 主要 包括 图 片 、 视 频 、js、css 和 一 些 资源 文件 等 ， 这 些 文件 因为 没有 状 
态 ， 所 以 分 离 比较 简单 ， 直 接 存放 到 相应 的 服务 器 就 可 以 了 ， 一 般 会 使 用 专门 的 域名 去 访问 ， 比 如 ， 新 浪 的 图 片 保存 在 sinaimg.cn 域 名 对 应 的 服务 器 中 ， 而 百度 的 图 片 则 是 通过 imgsrc.baidu.com 二 级 域名 
访问 的 ， 通 过 不 同 的 域名 可 以 让 浏览 器 直接 访问 资源 服务 器 而 不 需要 再 访问 应 用 服务 器 了 ， 这 时 的 架构 如 图 1-8 所 示 。 


数据 库 服务 器 


服务 硼 


图 1-8 ”应 用 和 静态 资源 分 离 架 构图 


1.5.2 ”页 面 缓存 


页 面 缓存 是 将 应 用 生成 的 页 面 缓存 起 来 ， 这 样 就 不 需要 每 次 都 重新 生成 页 面 了 ， 从 而 可 以 节省 大 量 CPU 资 源 ， 如 果 将 缓存 的 页 面 放 到 内 存 中 速度 就 更 快 了 。 如 果 使 用 了 Nginx 服 务 器 就 可 以 使 用 它 自 带 
的 缓存 功能 ， 当 然 也 可 以 使 用 专门 的 Sgquid 服 务 器 。 页 面 缓存 的 默认 失效 机 制 一 般 是 按 缓存 时 间 处 理 的 ， 当 然 也 可 以 在 修改 数据 之 后 手动 让 相应 缓存 失效 。 


多 知道 点 


有 部 分 经 常 变化 的 数据 的 页 面 怎么 使 用 页 面 缓存 


页 面 缓存 主要 是 使 用 在 数据 很 少 发 生变 化 的 页 面 中 ， 但 是 有 很 多 页 面 是 大 部 分 数据 都 很 少 发 生变 化 ， 而 其 中 有 很 少 一 部 分 数据 变化 的 频率 却 非 常 高 ， 比 如 ， 一 个 显示 文章 的 页 面 正 常 来 说 是 完全 可 以 静 
态 化 的 ， 但 是 如 果 在 文章 后 面 有 “ 顶 ” 和 “ 踩 ” 的 功能 而 且 显示 的 有 相应 的 数量 ， 这 个 数据 的 变化 频率 就 比较 高 了 ， 这 就 会 影响 静态 化 ， 在 电 商 系统 中 显示 商品 详情 的 页 面 中 的 销售 数量 也 是 这 种 情况 ， 对 
于 这 个 问题 可 以 先生 成 静态 页 面 然后 使 用 Ajax 来 读 取 并 修改 相应 的 数据 ， 这 样 就 可 以 一 举 两 得 了 ， 既 可 以 使 用 页 面 缓 存 也 可 以 实时 显示 一 些 变化 频率 高 的 数据 了 。 


1.5.3 ”集群 与 分 布 式 


集群 和 分 布 式 处 理 都 是 使 用 多 台 服 务 器 进行 处 理 的 ， 集 群 是 每 台 服 务 器 都 具有 相同 的 功能 ， 处 理 请 求 时 调用 哪 台 服务 器 都 可 以 ， 主 要 起 分 流 的 作用 ， 分 布 式 是 将 不 同 的 业务 放 到 不 同 的 服务 器 中 ， 处 理 
一 个 请 求 可 能 需要 用 到 多 台 服 务 器 ， 这 样 就 可 以 提高 一 个 请 求 的 处 理 速 度 ， 而 且 集 群 和 分 布 式 也 可 以 同时 使 用 ， 结 构图 如 图 1-9 所 示 。 


集群 有 两 个 方式 : 一 种 是 静态 资源 集群 。 另 一 种 是 应 用 程序 集群 。 静 态 资源 集群 比较 简单 ， 而 应 用 程序 集群 就 有 点 复杂 了 。 因 为 应 用 程序 在 处 理 过 程 中 可 能 会 使 用 到 一 些 缓存 的 数据 ， 如 果 集 群 就 需要 
同步 这 些 数据 ， 其 中 最 重要 的 就 是 session ，Session 同 步 也 是 应 用 程序 集群 中 非常 核心 的 一 个 问题 。Session 同 步 有 两 种 处 理 方式 : 一 种 是 在 session 发 生变 化 后 自动 同步 到 其 他 服务 器 ， 另 外 一 种 方式 是 
一 个 程序 统一 管理 Session。 所 有 集群 的 服务 器 都 使 用 同一 个 session，Tomcat 默 认 使 用 的 就 是 第 一 种 方式 ， 通 过 简单 的 配置 就 可 以 实现 ， 第 二 种 方式 可 以 使 用 专门 的 服务 器 安装 Memcached 等 高 效 的 缓存 
程序 来 统一 管理 Session ， 然 后 在 应 用 程序 中 通过 重 写 Request 并 覆盖 getSession 方 法 来 获取 指定 服务 器 中 的 Session。 对 于 集群 来 说 还 有 一 个 核心 的 问题 就 是 负载 均衡 ， 也 就 是 接收 到 一 个 请 求 后 具体 分 配 
到 哪个 服务 器 去 处 理 的 问题 ， 这 个 问题 可 以 通过 软件 处 理 也 可 以 使 用 专门 的 硬件 (如 F5) 解决 。 


业务 2 服务 需 群 


业务 2 服务 器 


业务 2 服务 需 
SN 业务 3 服务 器 群 
业务 3 服务 人 需 
业务 1 服务 需 群 
业务 3 服务 需 
大 | 
业务 1 服务 需 


业务 2 服务 需 群 


图 1-9 应 用 程序 分 布 式 集群 结构 图 


另外 笔者 还 想到 了 一 种 思路 可 以 简单 地 解决 Session 同 步 的 问题 ，Session 需 要 同步 的 本 质 原因 就 是 要 使 用 不 同 的 服务 器 给 同一 个 用 户 提供 服务 ， 如 果 负 载 均衡 在 分 配 请 求 时 可 以 将 同一 个 用 户 (如 按 
IP) 分 配 到 同一 台 服 务 器 进行 处 理 也 就 不 需要 session 同步 了 ， 而 且 这 种 方法 一 般 也 不 会 对 负载 均衡 带 来 太 大 的 问题 ， 如 果 考 虑 到 稳定 性 ， 为 了 防止 有 机 器 宕 机 后 丢失 数据 还 可 以 将 集群 的 服务 器 分 成 多 个 
组 ， 然 后 在 小 范围 的 组 (如 2、3 台 服务 器 ) 内 同步 Session。 


架设 分 布 式 应 用 程序 是 一 件 非常 复杂 的 事情 ，Session 同 步 肯定 是 需要 的 ， 分 布 式 事务 处 理 和 各 个 节点 之 间 复 杂 的 依赖 关系 也 是 分 布 式 中 非常 复杂 的 问题 ， 如 果 要 使 用 分 布 式 一 定 要 做 好 足够 的 准备 。 


1.54 ” 反 向 代理 


反 向 代理 指 的 是 客户 端 直接 访问 的 服务 器 并 不 真正 提供 服务 ， 它 从 别 的 服务 器 获取 资源 然后 将 结果 返回 给 用 户 的 ， 如 图 1-10 所 示 。 


实际 服务 天 


ma | 反 向 代理 | 一 服务 器 
浏览 钟 e 一 | 服务器。 一 全 程序 


1-10 ” 反 向 代理 服务 器 


多 知道 点 


反 向 代理 服务 器 和 代理 服务 器 的 区 别 


代理 服务 器 的 作用 是 代 我 们 获取 想 要 的 资源 然后 将 结果 返回 给 我 们 ， 所 要 获取 的 资源 是 我 们 主动 告诉 代理 服务 器 的 ， 比 如 ， 我 们 想 访问 Facebook， 但 是 直接 访问 不 了 ， 这 时 就 可 以 让 代理 服务 器 访问 ， 
然后 将 结果 返回 给 我 们 。 


反 向 代理 服务 器 是 我 们 正常 访问 一 台 服 务 器 的 时 候 ， 服 务 器 自己 调用 了 别 的 服务 器 的 资源 并 将 结果 返回 给 我 们 ， 我们 自己 并 不 知道 。 


代理 服务 器 是 我 们 主动 使 用 的 ， 是 为 我 们 服务 的 ， 它 不 需要 有 自己 的 域名 ; 反 向 代理 服务 器 是 服务 器 自己 使 用 的 ， 我 们 并 不 知道 ， 它 有 自己 的 域名 ， 我 们 访问 它 跟 访问 正常 的 网 址 没有 任何 区 别 。 


反 向 代理 服务 器 可 以 和 实际 处 理 请 求 的 服务 器 在 同一 台 主机 上 ， 而 且 一 台 反 向 代理 服务 器 也 可 以 访问 多 台 实 际 处 理 请 求 的 服务 器 。 反 向 代理 服务 器 主要 有 三 个 作用 : @ 可 以 作为 前 端 服务 器 跟 实 际 处 理 
请 求 的 服务 器 (如 Tomcat) 集成 ; @ 可 以 用 做 负载 均衡 ; @ 转 发 请 求 ， 比 如 ， 可 以 将 不 同类 型 的 资源 请 求 转发 到 不 同 的 服务 器 去 处 理 ， 可 以 将 动态 资源 转发 到 Tomcat、Php 等 动态 程序 而 将 图 片 等 静态 资 
源 的 请 求 转发 到 静态 资源 的 服务 器 ， 另 外 也 可 以 在 url 地 址 结构 发 生变 化 后 将 新 地 址 转发 到 原来 的 旧地 址 上 。 


1.55 CDN 


CDN 其 实 是 一 种 特殊 的 集群 页 面 缓存 服务 器 ， 它 和 普通 集群 的 多 台 页 面 缓存 服务 器 比 主 要 是 它 存放 的 位 置 和 分 配 请 求 的 方式 有 点 特殊 。CDN 的 服务 器 是 分 布 在 全 国 各 地 的 ， 当 接收 到 用 户 的 请 求 后 会 将 
请 求 分 配 到 最 合适 的 CDN 服 务 器 节点 获取 数据 ， 比 如 ， 联 通 的 用 户 会 分 配 到 联通 的 节点 ， 电 信 的 用 户 会 分 配 到 电信 的 节点 ; 另外 还 会 按照 地 理 位 置 进行 分 配 ， 北 京 的 用 户 会 分 配 到 北京 的 节点 ， 上 海 的 用 户 
会 分 配 到 上 海 的 节点 。CDN 的 每 个 节点 其 实 就 是 一 个 页 面 缓存 服务 器 ， 如 果 没 有 请 求 资源 的 缓存 就 会 从 主 服务 器 获取 ， 和 否则 直接 返回 缓存 的 页 面 。CDN 分 配 请 求 的 方式 比较 特殊 ， 它 并 不 是 使 用 普通 的 负载 
均衡 服务 器 来 分 配 的 ， 而 是 用 专门 的 CDN 域 名 解析 服务 器 在 解析 域名 的 时 候 就 分 配 好 的 ， 一 般 的 做 法 是 在 ISP 那 里 使 用 CNAME 将 域名 解析 到 一 个 特定 的 域名 ， 然 后 再 将 解析 到 的 那个 域名 用 专门 的 CDN 服 
务 器 解析 到 相应 的 CDN 节 点 ， 结 构图 如 图 1-11 所 示 。 


正常 的 DNS 服务 器 [CNAME 日 标 城 


CDN 的 DNS 服务 器 


用 户 访问 的 域名 


CDN 节 点 


如 果 没 有 缓冲 则 
从 主 服 务 融 获 取 


服务 需 


程序 


图 1-11 CDN 结 构 


第 二 步 访问 CDN 的 DNS 服务 器 是 因为 CNAME 记 录 的 目标 域名 使 用 NS 记录 指向 了 CDN 的 DNS 服务 器 。CDN 的 每 个 节点 可 能 也 是 集群 了 多 台 服 务 器 。CDN 的 原理 并 不 复杂 ， 不 过 如 果 要 自己 去 架设 则 需 
要 投入 大 量 的 资金 ， 现 在 有 专门 的 CDN 服 务 商 ， 可 以 直接 购买 它们 的 服务 。 


1.6 ”底层 的 优化 


我 们 前 面 讲 到 的 所 有 架构 都 是 建立 在 最 前 面 介绍 的 基础 架构 之 上 的 ， 而 且 很 多 地 方 都 需要 通过 网 络 传输 数据 ， 如 果 可 以 加 快 网 络 传输 的 速度 ， 那 将 会 让 整个 系统 从 根本 上 得 到 改善 。 网 络 传输 数据 都 是 
按照 各 种 协议 进行 的 ， 不 过 协议 并 不 是 不 可 以 改变 ，Google 就 迈 出 了 这 一 步 ， 它 制定 了 Quic、Spdy 等 协议 来 传输 数据 ，Quic 比 TCP 效 率 高 而 且 比 UDP 安全 ，Spdy 协 议 在 现 有 HTTP 协 议 的 基础 上 增加 了 很 
多 新 特性 ， 提 高 了 传输 的 效率 ， 不 过 有 些 特性 已 经 包含 到 了 HTTP/2 协 议 中 ， 而 且 Google 也 已 经 放弃 了 Spdy 而 使 用 HTTP/2 了 。 


7 WE 


网 站 架构 的 整个 演变 过 程 主要 是 围绕 大 数据 和 高 并 发 这 两 个 问题 展开 的 ， 解 决 的 方案 主要 分 为 使 用 缓存 和 使 用 多 资源 两 种 类 型 。 多 资源 主要 指 多 存储 (包括 多 内 存 ) 、 多 CPU 和 多 网 络 ， 对 于 多 资源 来 
说 又 可 以 分 为 单个 资源 处 理 一 个 完整 的 请 求 和 多 个 资源 合作 处 理 一 个 请 求 两 种 类 型 ， 如 多 存储 和 多 CPU 中 的 集群 和 分 布 式 ， 多 网 络 中 的 CDN 和 静态 资源 分 离 。 理 解 了 整个 思路 之 后 就 抓 住 了 架构 演变 的 本 


质 ， 而 且 自 己 可 能 还 可 以 设计 出 更 好 的 架构 。 


一 个 网 站 具体 使 


要 先 将 自己 的 业务 优化 好 ， 这 是 基础 中 的 基础 ， 非 常 重要 ! 


无 论 架构 还 是 协议 都 要 以 正确 的 态度 对 待 ， 它 们 都 是 为 了 解决 特定 的 问题 而 设计 出 来 的 


灵活 。 


第 2 章 ”常见 协议 和 标准 


什么 样 的 架构 需要 根据 实际 需要 做 出 选择 ， 网 站 架构 并 不 是 竞技 场 ， 更 不 是 使 
理 的 架构 首先 需要 理解 每 种 架构 所 针对 的 问题 和 它 背 后 的 本 质 ， 只 有 这 样 才能 真正 把 架构 


的 技术 越 


本 章 介绍 Java Web 开 发 中 常用 的 协议 和 标准 ， 其 中 包括 DNS 协议 、TCP/IP 协 议 、HTTP 协 议和 Java Web 开 发 中 的 Servlet。 


2.1 DNS 协议 


DNS 协议 的 作 


电脑 自己 去 处 理会 比较 慢 ， 另 外 域名 和 IP 的 对 应 关系 也 不 像 电 视频 道 那样 稳定 ， 而 是 经 常 在 变化 ， 所 以 就 需要 有 专门 将 域名 解析 为 |P 的 服务 器 ， 这 就 是 “DNS 服务 器 ”， 我 人 
返回 相应 的 I!P， 在 Windows 中 可 以 使 用 nslookup 命 令 来 查看 DNS 解析 的 结果 ， 如 使 


是 将 域名 解析 为 |P。 我 们 知道 网 络 上 每 个 站 点 的 位 置 是 使 有 


杂 越 好 ， 只 要 可 以 满足 自己 的 需 
做 解决 问题 的 工具 ， 而 不 是 为 了 架构 而 架构 最 后 问题 不 一 定 能 解决 还 浪费 了 资源 。 另 外 在 使 


、 可 以 解决 自己 所 遇 到 的 问题 就 可 以 了 。 要 想 设计 出 合 
杂 架 构 之 前 一 定 


， 我 们 要 认真 并 且 谦 虚 地 学 习 ， 不 过 也 不 需要 将 它们 当成 神圣 不 可 侵犯 的 东西 ， 它 们 的 本 质 还 是 为 我 们 解决 问题 
的 工具 。 另 外 这 些 架构 、 协 议 以 及 相关 的 产品 都 是 经 过 实际 的 考验 可 以 解决 问题 的 ， 不 过 也 并 不 是 说 它们 就 是 最 优 的 解决 方案 ， 我 们 只 有 真正 理解 了 它们 所 针对 的 问题 才能 对 它们 理解 得 更 透彻 、 使 


得 更 


IP 来 确定 的 ， 所 以 要 想 访 问 一 个 网 站 首先 就 要 知道 它 的 IP， 不 过 由 数字 组 成 的 IP 记 起 来 实在 不 方便 ， 所 以 就 设计 了 比较 好 记 
的 域名 来 代替 IP， 这 就 像 我 们 平时 看 电视 的 时 候 只 需要 记 着 “中 央 一 套 ” “中央 二 套 ”， 而 不 需要 去 记 它 们 是 什么 频率 ， 不 过 实际 传输 还 是 需要 按 频 率 来 传输 的 (对 于 老式 
们 选择 了 相应 的 频道 后 电视 就 会 自动 接收 相应 频率 的 数据 ， 频 道 和 频率 的 转换 过 程 是 电视 机 自己 来 处 理 的 ， 但 这 种 方式 并 不 适合 网 络 上 的 域名 和 IP 的 转换 ， 首 先是 | 


天 线 接收 的 电视 来 说 ) ， 在 我 
为 域名 的 数量 非常 多 ， 如 果 让 客户 端的 


nslookup 命 令 查看 淘宝 的 解析 记录 的 结果 如 


] 把 域名 发 过 去 它 就 可 以 给 我 们 


图 2-1 所 示 。 


C:VJsers\ 国 pnslookup www.taobao -com 


服务 器 : 


fAddress: 


威 应 答 : 


小 = 


: 


publici.1ii4dns.com 
114.114.114.114 


www.gs1lb.taobao.com.danuoyi.thbcache.com 


Addresses: 


fliases: 


112 .25 .59 .51 
112.25.59 .41 
www .上 taohbao .com 


从 这 里 可 以 看 出 我 现在 使 


是 www.gslb.taobao.com.danuoyi.tbcache.com。 


图 2-1 使 用 nslookup 命 令 查看 淘宝 IP 


的 DNS 服 务 器 地 址 是 114.114.114.114， 解 析 到 www.taobao.com 的 IP 是 112.25.59.51 和 112.25.59.41， 而 且 它 是 通过 CNAME 方 式 解 析 的 ， 原 始 设 置 IP 的 域名 


世界 各 地 有 很 多 DNS 服务 器 ，1SP 会 给 我 们 提供 默认 的 DNS 服务 器 ， 也 有 一 些 大 型 公用 的 DNS 服务 器 可 以 使 用 ， 比 如 Google 的 8.8.8.8 和 国内 的 114.114.114.114。 我 们 直接 访问 的 DNS 服务 器 叫 本 地 
DSN 服 务 器 ， 它 本 身 也 没有 域名 和 IP 的 对 应 关系 ， 在 我 们 发 出 请 求 的 时 候 它 会 从 主 DNS 服务 器 获取 然后 保存 到 缓存 中 ， 下 次 再 有 相同 的 域名 请 求 时 直接 从 缓存 中 获取 就 可 以 了 。 


使 


域名 代 蔡 IP 主 要 是 为 了 方便 记忆 ， 不 过 域名 很 多 时 候 


系 ， 


起 来 也 不 是 那么 方便 ， 如 果 再 加 上 很 长 的 子 


录 和 查询 参数 ， 基 本 就 成 了 只 有 机 器 和 专业 人 员 才 能 读 得 懂 的 内 容 了 ， 正 
有 了 很 大 的 需求 。 可 能 有 人 会 觉得 导航 站 主要 是 将 键盘 输入 改 成 点 击 打开 从 而 方便 了 操作 而 不 是 域名 的 问题 ， 当 然 操 作 方 式 改变 也 是 非常 


为 这 样 导 航 网 站 才 
不 方便 也 是 非常 重要 的 一 个 因 


要 的 一 个 


素 ， 不 过 域名 本 身 使 


一 定 程度 满足 了 这 方面 的 需求 。 如 果 从 这 个 需求 出 发 仔细 琢磨 应 该 还 有 很 大 的 发 展 空间 。 


2.2 TCP/IP 协 议 与 Socket 


TCP/IP 协 议 通常 放 在 一 起 来 说 ， 不 过 它们 是 两 个 不 同 的 协议 ， 所 起 的 作 | 
址 ， 具 体 传输 的 工作 交 给 TCP 来 完成 ， 这 就 像 快递 送 货 一 样 ， 货 单 上 填写 地 址 


签字 等 就 相当 于 TCP 协 议 。 


TCP 在 传输 之 前 会 进行 三 次 沟通 ， 一 般 称 为 “三 次 握手 ”， 


这 一 点 从 百度 指数 里 查看 “淘宝 网 ”的 搜索 量 就 可 以 看 出 来 ， 同 样 是 输入 但 是 很 多 人 是 通过 在 百度 搜 “淘宝 网 ”打开 淘宝 的 而 不 是 直接 在 地 址 栏 输入 www.taobao.com 打 开 的 。 其 实 微 信 的 公众 号 也 从 


也 不 一 样 。IP 协 议 是 用 来 查找 地 址 的 ， 对 应 着 网 际 互联 层 ，TCP 协 议 是 用 来 规范 传输 规则 的 ， 对 应 着 传输 层 。IP 只 负责 找到 地 
的 规则 以 及 怎么 根据 填写 的 内 容 找到 客户 ， 这 就 相当 于 IP 协 议 ， 而 送 货 时 要 先 打 电话 ， 然 后 将 货物 送 过 去 ， 最 后 客户 签收 时 要 


传 完 数据 断 开 | 


的 时 候 要 进行 四 次 沟通 ， 一 般 称 为 “四 次 挥手 ”。 


要 理解 这 个 过 程 首先 需要 理解 TCP 中 的 两 个 序号 和 三 个 标志 位 的 含义 : 


“ seq: sequence number 的 缩写 ， 表 示 所 传 数 据 的 序号 。TCP 传 输 时 每 一 个 字 节 都 有 一 个 序号 ， 发 送 数据 时 会 将 数据 的 第 一 个 序号 发 送 给 对 方 ， 接 收 方 会 按 序 号 检查 是 否 接 收 完整 了 ， 如 果 没 接收 完整 就 


需要 重新 传送 ， 这 样 就 可 以 保证 数据 的 完整 性 。 


“ ack: acknoledgement number 的 缩写 ， 表 示 确 认 号 。 接 收 端 用 它 来 给 发 送 端 反馈 已 经 成 功 接收 到 的 数据 信息 的 ， 它 的 值 为 希望 接收 的 下 一 个 数据 包 起 始 序号 ， 也 就 是 ack 值 所 代表 的 序号 前 面 数 据 已 经 成 


功 接收 到 了 。 


“ ACK: 确认 位 ， 只 有 ACK=1 的 时 候 ack 才 起 作用 。 正 常 通信 时 ACK 为 1， 第 一 次 发 起 请 求 时 因为 没有 需要 确认 接收 的 数据 所 以 ACK 为 0。 


“ SYN: 同步 位 ， 用 于 在 建立 连接 时 同步 序号 。 刚 开始 建立 连接 时 并 没有 历史 接收 的 数据 ， 所 以 ack 也 就 没 办 法 设置 ， 这 时 按照 正常 的 机 制 就 无 法 运行 了 ，SYN 的 作用 就 是 来 解决 这 个 问题 的 ， 当 接收 端 
接收 到 SYN=1 的 报 文 时 就 会 直接 将 ack 设 置 为 接收 到 的 seq+1 的 值 ， 注 意 这 里 的 值 并 不 是 校 验 后 设置 的 ， 而 是 根据 SYN 直 接 设 置 的 ， 这 样 正常 的 机 制 就 可 以 运行 了 ， 所 以 SYN 叫 同步 位 。 需 要 注意 的 是 ，SYN 
会 在 前 两 次 握手 时 都 为 1， 这 是 因为 通信 的 双方 的 ack 都 需要 设置 一 个 初始 值 。 


“ FIN: 终止 位 ， 用 来 在 数据 传输 完毕 后 释放 连接 。 


整个 传输 过 程 如 图 2-2 所 示 。 
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图 2-2 TCP 传 输 过 程 图 


图 中 上 部 为 三 次 握手 ， 下 部 为 四 次 挥手 ， 这 里 的 


次 挥手 中 画 的 是 客户 端 提出 的 终止 连接 ， 在 实际 传输 过 程 中 也 有 可 能 是 服务 端 提出 终止 连接 ， 它 们 的 处 理 过 程 都 是 一 样 的 。TCP 的 传输 是 双全 工 模 


式 ， 也 就 是 说 传输 的 双方 是 对 等 的 ， 可 以 同时 传输 数据 ， 所 以 无 论 连 接 还 是 关闭 都 需要 对 双方 同时 进行 。 三 次 握手 中 前 两 次 可 以 保证 服务 端 可 以 正确 接收 并 返回 请 求 ， 后 两 次 可 以 保证 客户 端 可 以 正确 接收 


并 返回 请 求 ， 而 且 在 三 次 握手 的 过 程 中 还 使 用 SYN 标 志 初始 化 了 双方 的 ack 值 。 四 次 挥手 就 是 双方 分 别 发 送 FIN 标 志 来 关闭 连接 并 让 对 方 确认 。 


三 次 握手 和 四 次 挥手 保证 了 连接 的 可 靠 性 ， 不 过 凡 对 


有 有 利 就 有 雌 ， 这 种 模式 也 有 它 的 缺点 ， 首 先是 在 传输 效率 上 会 比较 低 ， 另 外 三 次 握手 的 过 程 中 客户 端 需要 发 送 两 次 数据 才 可 以 建立 连接 ， 这 种 特性 


可 能 被 一 些 别有用心 的 和 人 利用， 比如， 发 出 第 一 次 握手 (并 接 到 第 二 次 握手 ) 后 就 不 回应 第 三 次 握手 了 ， 这 时 服务 端 会 以 为 是 第 二 次 握手 的 数据 在 传输 过 程 中 丢失 了 ， 然 后 重新 发 送 第 二 次 握手 ， 默 认 情 况 
下 会 一 直 发 送 五 次 ， 如 果 发 送 五 次 后 还 收 不 到 第 三 次 握手 则 会 丢弃 请 求 ， 如 果 是 个 别 这 种 请 求 当然 也 没什么 关系 ， 可 凡事 就 怕 一 个 多 字 ， 当 有 大 量 这 种 请 求 时 就 麻烦 了 ， 这 时 服务 器 就 会 浪费 大 量 的 资源 甚 
至 可 能 导致 无 法 处 理 正 常 的 请 求 ， 这 就 是 DDOS 攻 击 中 的 SYN Flood 攻 击 ， 对 于 这 种 攻击 的 一 种 应 对 方法 是 设置 第 二 次 请 求 的 重 发 次 数 (tcp_synack_retries) ， 不 过 重 发 的 次 数 太 小 也 可 能 导致 正常 的 请 求 
中 因为 网 络 没有 收 到 第 二 次 握手 而 连接 失败 的 情况 ， 具 体 设置 为 多 少 合适 ， 还 需要 根据 实际 情况 判断 ， 当 然 如 果 资金 充足 也 可 以 使 用 硬 防 。 


于 传输 层 的 协议 除了 TCP 还 有 UDP， 它 们 的 


主要 是 TCP 是 有 连接 的 ，UDP 是 没有 连接 的 ， 也 就 是 说 TCP 协 议 是 在 沟通 好 后 才 会 传 数据 ， 而 UDP 协议 是 拿 到 地 址 后 直 就 传 了 了， 这 样 产生 的 结果 就 是 


TCP 协 议 传输 的 数据 更 可 靠 ， 而 UDP 传输 的 速度 更 快 。TCP 就 像 是 打 电 话 ， 需 要 先 拨 通 对 方 号 码 才能 通信 ， 而 UDP 就 像 是 使 用 对 讲 机 ， 拿 起 来 就 可 以 直接 讲话 。 通 常 视频 传输 、 语 音 传输 等 对 完整 性 要 求 不 


高 而 对 传输 速度 要 求 


高 并 且 数 据 量 大 的 通信 使 


HTTP 协 议 的 底层 传输 默认 使 用 的 是 可 靠 的 TCP 协 议 ， 


TCP 和 UDP 之 间 ， 不 过 现在 还 没有 广泛 使 用 。 


TCP/IP 协 议 只 是 一 套 规则 ， 并 不 能 


UDP 比较 多 ， 而 邮件 、 网 页 等 一 般 使 用 TCP 协 议 。 


不 过 它 对 互联 网 的 高 速 发 展 带 来 了 很 大 的 制约 ，Google 制 定 了 一 套 基 于 UDP 的 QUIC (Quick UDP Internet Connection) 协议 ， 这 种 协议 基于 


2.3 _ HTTP 协议 


HTTP 协 议 是 应 


层 的 协议 ， 在 TCP/IP 协 议 接收 到 数 所 


体 工 作 ， 就 像 是 程序 中 的 接口 一 样 ， 而 Socket 是 TCP/IP 协 议 的 一 个 具体 的 实现 ， 第 3 章 给 大 家 介绍 Java 中 Socket 的 具体 用 法 。 


居 之 后 需要 通过 HTTP 协 议 来 解析 才 可 以 使 用 。 就 像 过 去 的 发 电报 一 样 ， 电 报 机 就 相当 于 Socket， 负 责 选 好 发 送 的 目标 并 将 内 容 发 过 去 ， 但 是 直接 发 


过 去 的 数据 “ 叶 咬 咬 ” 并 不 能 直接 使 用 ， 还 需要 解码 (在 发 送 前 需要 先 编码 再 发 送 ) 后 才能 用 ， 电 报 中 的 编码 和 解码 就 相当 于 网 络 传输 中 的 HTTP 协 议 。 


HTTP 协 议 中 的 报 文 结构 非常 重要 。HTTP 中 报 文 分 为 请 求 报 文 (request message) 和 响应 报 文 (response message) 两 种 类 型 ， 这 两 种 类 型 都 包括 三 部 分 : 首 行 、 头 部 和 主体 。 请 求 报 文 的 首 行 是 


请 求 行 ， 包 括 方法 (请求 类 型 ) 、 


URL 和 HTTP 版 本 三 项 内 容 ， 响 应 请 求 的 首 行 是 状态 行 ， 包 括 HTTP 版 本 、 状 态 码 和 简短 原因 三 项 内 容 ， 其 中 原因 可 有 可 无 。 头 部 保存 一 些 键 值 对 的 属性 ， 用 冒号 “: ”分 


割 。 主 体 保存 具体 内 容 ， 请 求 报 文中 主要 保存 POST 类 型 的 参数 ， 响 应 报 文中 保存 页 面 要 显示 的 结果 。 首 行 、 头 部 和 主体 以 及 头 部 的 各 项 内 容 用 回 车 换行 (\r\n) 分 割 ， 另 外 头 部 和 主体 之 间 多 一 个 空 行 ， 也 
就 是 有 两 个 连续 的 回 车 换行 。 它 们 的 结构 如 图 2-3 所 示 。 


请 求 报 文 


啊 应 报 文 


方法 URL HTTP 版 本 \r\n HTTP 版 本 状态 码 简短 原因 \r\n 


参数 1: 值 1\r\n 
参数 2， 值 2\r\n 
NANn 


主体 


参数 1: 值 1\r\n 
参数 2: 值 2\rn 


oo o Mn 
\r\in 
主体 


图 2-3 ”HTTP 报 文 结构 


请 求 报 文中 的 方法 指 GET、HEAD、POST、PUT、DELETE 等 类 型 ， 响 应 报 文中 的 状态 码 就 是 Response 中 的 status， 一 共 可 以 分 为 5 类 : 


1XX: 信息 性 状态 码 。 


. 2XX: 成 功 状态 码 ， 如 200 表 示 成 功 。 


“ 3XX: 重 定向 状态 码 ， 如 301 表 示 重 定向 。 


: 4XX: 客户 端 错误 状态 码 ， 如 404 表 示 没 找到 请 求 的 资源 。 


"5XX: 服务 端 错误 状态 码 ， 如 500 表 示 内 部 错误 。 


报 文 信息 可 以 通过 firefox 的 firebug 插 件 来 查看 ， 比 如 ， 要 看 www.csdn.net 网 址 请 求 的 报 文 ， 可 以 在 安装 好 firefox 和 firebug 揪 件 后 按 F12 打 开 firebug 的 面板 ， 然 后 选择 “网 络 ” 下 面 的 “HTML”， 并 
输入 网 址 发 起 请 求 ， 这 时 firebug 就 会 记录 下 来 ， 如 图 2-4 所 示 。 


控制 侣 HTML CSS 脚本 DOM Cookies 


清除 ”保持 | 全 部 CSS JjJavaScript XHR 图 片 揪 件 媒体 字体 


由 四 | 


外 芝 | 上 也 


本 | 此 


GET www.csdn.net OK csdn.net 

GET cc.php?tt=1443093789&l=b..é¢ 200 OK 58.52.132.98:32001 
GET collect?v=1& v=j39&a=140.. 302Found google-analytics,com 
GET collect?v=1&aip=1la&t=dc& .4 302F stats,g,doubledidk.net 
GET rr.php?c=http%3A%Y2F%2Fwy OK 58.52.132.98:32001 


GET upload.html 
个 请 求 


ask.csdn.net 


图 2-4 ”Firebug 记 录 请 求 


这 时 点 击 URL 前 面 的 加 号 就 可 以 展开 详细 信息 ， 如 图 2-5 所 示 。 


三 唱 《 》 涝 控制 台 HTML css 脚本 DOM 网络 ~ Cookies 
由 | 清除 保 竺 | 全 部 |HTML | CSS JavaScript XHR 图片” 插件 媒体 字体 


贺 


| URL | 状态 | 域 | 大 小 ”运程 外 
[El5ET www.csdn.net 200 OK csdn.net 20,5KB 101.200.29.44:80 


EF wm 壤 


Connection kssp-alivs 
Content-Encoding szip 
Content-Type text/html; charset=utE-8 
Date Thu, 24 Sep 2015 11:16:18 GMT 
Etag 到 "5603dal13-192b8” 
Keep-Alive timsout=20 
Thu, 24 Sep 2015 11:10:11 GMT 
openresty 
chunked 
Accept-~EncodingE，Accept-Encoding 


text/html, application/xhtml+xml, application/xm1:q=0. 9, */*:q=0. 8 
Ezip, deflate 

zh-CN, zh;q=0. 8, en-US;q=0. 5, en;qg=0.3 

kssp-alive 

1 


www. Csdn. net 
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0 


图 2-5 请求 头 信息 


中 上 边 是 响应 的 头 信息 ， 下 面 是 请 求 的 头 信息 ， 在 “响应 ”选项 卡 中 可 以 看 到 响应 报 文 的 主体 。 不 过 这 时 的 头 信息 是 经 过 格式 化 之 后 的 ， 如 果 想 看 原始 的 可 以 点 击 “ 原 始 头 信息 ”来 查看 ， 如 图 2-6 所 


可 县 《 》 涝 控制 和 HTML css 脚本 DOM | 网络 ~ | cookies 
由 | 清除 保持 | 全 部 |HTML | CSS JavaScript XHR 图 片 插件 媒体 字体 


| URL | 状态 | 域 
GET www.csdn.net 200 OK csdn.net 


头 信息 ”响应 HTML 和 弓 存 


HTTP/1. 1 200 OK 

Server: openresty 

Date: Thu, 24 Sep 2015 i11:16:18 GMT 
Content-Type: text/html:; charset=utf-8 
Transfer~Encoding: chunked 

Connection: keep-alive 

Keep-Alive: timeout=20 

Vary: Accept~Encodine, Accept~Encodinge 
Last-Modified: Thu, 24 Sep 2015 11:10:11 GT 
Etag: W5603dal3-192b8” 
Content-Encodine: gzip 


GET / HTTP/1.1 

Host: WE csdn. net 

User~Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0 
Accept: text/html, application/xhtml+xml, spplication/xml:;q=0. 9, */*:;q-0.8 
Accept~Language: zh-CN, zh;q=0. 8, en-USs :9q=0. 5, en;q=0.3 

Accept-Encoding: gzip, deflate 

DNT: 1 

Connection: keep-alive 


图 2-6 请求 原 始 头 信息 


从 这 里 就 可 以 看 到 请 求 报 文 和 响应 报 文 的 首 行 和 头 部 。 我 们 会 在 后 面 自己 动手 写 一 个 实现 了 HTTP 协 议 的 简单 例子 。 


2.4 ” ”Servlet 与 Java Web 开 发 


Servlet 是 J2EE 标 准 的 一 部 分 ， 是 Java Web 开 发 的 标准 。 标 准 比 协议 多 了 强制 性 的 意义 ， 不 过 它们 的 作用 基本 是 一 样 的 ， 都 是 用 来 制定 统一 的 规矩 ， 因 为 Java 是 一 种 具体 的 语言 ， 所 以 为 了 统一 的 实现 
它 可 以 制定 自己 的 标准 。 


通过 前 面 的 TCP/IP 协 议 、HTTP 协 议 已 经 可 以 得 到 数据 了 ，Servlet 的 作用 是 对 接收 到 的 数据 进行 处 理 并 生成 要 返回 给 客户 端的 结果 ， 这 就 像 电报 中 接收 到 电报 并 翻译 成 明文 后 还 需要 有 人 来 决策 并 作出 
回复 内 容 一 样 。 


Servlet 制 定 了 Java 中 处 理 Web 请 求 的 标准 ， 我 们 只 需要 按照 标准 规定 的 去 做 就 可 以 了 。 不 过 还 是 那 句 话 ， 规 范 自己 是 不 能 干 活 的 ， 标 准 一 样 也 不 能 自己 干 活 ， 要 想 使 用 Servlet 需 要 有 相应 的 Servlet 容 
器 才 行 ， 比 如 ， 我 们 常见 的 Tomcat 就 是 一 个 Servlet 容 器 ， 后 面 会 给 大 家 具体 分 析 Tomcat。 


第 3 章 DNS 的 设置 


本 章 介 绍 DNS 的 设置 ， 包 括 DNS 解 析 、Windows 7 设置 DNS 服务 器 和 Windows 设 置 本 机 域名 和 IP 的 对 应 关系 三 部 分 内 容 。 


3.1 DNS 解析 


我 们 知道 DNS 服务 器 可 以 将 域名 解析 为 相应 的 |P， 但 是 DNS 服务 器 是 怎么 知道 域名 和 IP 的 对 应 关系 的 呢 ? 这 个 就 需要 域名 的 所 有 者 自己 将 域名 解析 到 对 应 的 !P 上 ， 这 样 DNS 服务 器 才能 查找 到 ， 不 同 的 


域名 运营 商都 有 自己 不 同 的 解析 页 面 ， 万 网 的 解析 页 面 如 图 3-1 所 示 。 
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图 3-1 万 网 域名 解析 页 面 


进入 万 网 的 “域名 解析 ”页 面 (在 “域名 ”里 找到 要 解析 的 域名 ， 然 后 直接 点 击 “ 解 析 ” 即 可 进入 “域名 解析 ”页 面 ) ， 在 页 面 中 点 击 “ 添 加 解析 ”按钮 就 可 以 添加 解析 记录 了 ， 万 网 的 解析 现在 一 共 
有 5 项 内 容 ， 它 们 的 含义 分 别 如 下 : 


“ 记录 类 型 : 域名 解析 有 很 多 种 解析 的 类 型 ， 如 常用 的 A 记录 和 CNAME 记 录 。A 记 录 是 将 域名 解析 到 IP (一 个 域名 可 以 有 多 条 A 记录 ) ，CNAME 记 录 是 将 域名 解析 到 另 一 个 域名 (也 就 是 作为 另 一 个 域 
名 的 别名 ) ， 查 找 时 会 返回 目标 域名 所 对 应 的 IP， 如 excelib.com 可 以 使 用 CNAME 记 录 解 析 到 www-.excelib.com， 这 样 访 问 excelib.com 时 DNS 服务 器 就 会 返回 www.excelib.com 对 应 的 IP， 这 么 做 有 三 个 好 处 : 
(www.excelib.com 可 能 会 有 多 条 解析 记录 ， 而 excelib.com 用 一 条 CNAME 记 录 就 可 以 完成 了 ; 加 在 www.excelib.com 的 IP 发 生变 化 时 ，excelib.com 不 需要 修改 解析 内 容 直接 就 可 以 自动 改变 ; 图 使 用 CDN 时 可 以 
将 用 户 直 接 访 问 的 域名 作为 一 个 别名 ， 然 后 将 指向 的 域名 通过 ns 记录 指定 CDN 专 用 的 DNS 服务 器 进行 解析 ， 这 样 用 户 访问 的 域名 解析 使 用 的 还 是 正常 的 DNS 服务 器 但 是 可 以 获取 到 CDN 的 DNS 服务 器 解析 的 
结果 。 


“主机 记录 : 就 是 域名 前 面 的 部 分 ， 如 www、bbs 等 ， 如 果 要 解析 顶级 域名 ， 也 就 是 域名 前 面 没 有 内 容 则 使 用 @ 代 替 。 


“ 解析 线路 : 这 是 万 网 新 增加 的 内 容 ， 很 多 别 的 运营 商 现在 还 没有 这 项 功能 ， 通 过 这 个 选项 可 以 将 不 同 的 线路 的 用 户 解 析 到 不 同 的 服务 器 ， 比 如 ， 将 联通 的 用 户 解析 到 一 个 服务 器 将 电信 的 用 户 解 析 到 
另外 一 个 服务 器 ， 这 样 就 可 以 实现 一 种 简单 的 CDN。 


“ 记录 值 : 解析 的 目标 值 ， 如 A 记 录 就 是 P，CNAME 记 录 就 是 对 应 的 目标 域名 。 
"TTL: 本 地 DNS 服务 器 缓存 解析 结果 的 时 间 。 


设置 完 之 后 点 击 保存 就 可 以 了 ， 一 个 域名 可 以 添加 多 条 解析 记录 。 


3.2 Windows 7 设置 DNS 服务 器 


我 们 可 以 对 自己 的 电脑 设置 自己 使 用 的 DNS 服务 器 ， 设 置 方法 是 从 控制 面板 中 找到 所 使 用 的 连接 并 从 属性 中 打开 TCP/IPv4 属 性 设置 页 进行 设置 ， 在 Windows 7 中 设置 方法 如 图 3-2 所 示 。 


网 党 和 Internet 


Re 锅 蝇 和 了 设置 。 否则 ， 


潍 集 种 


A 9 自动 于 得 IF 地 it) 
| B 加 
加 于 He) 个 使 用 下 面 的 下 地 址 68) 
连接 / 断 开 (O) IF 地 址 I) 
子 网 接 码 Q) 
默认 网 关 0D) 


辐 自动 获得 DRS 服务 器 地 址 DB) 
加 使 用 下 面 的 DNS 服务 器 地 址 EE): 
首选 IW5 服务 器 F): 114 .114 .114 .114 


有 DNS 服务 器 ): 


退出 时 验证 设置 部) 


图 3-2 Windows 7 设置 DNS 服务 器 


有 时 候 可 能 出 现 浏览 器 上 不 了 网 ， 而 直接 使 用 |P 连 接 的 程序 (如 QQ) 可 以 联网 ， 这 时 很 可 能 就 是 DNS 出 了 问题 ， 可 以 尝试 用 上 面 的 方法 自己 设置 DNS 服务 器 来 试 一 试 。 


3.3 ”Windows 设 置 本 机 域名 和 IP 的 对 应 关系 


在 自己 的 电脑 里 也 可 以 设置 域名 和 IP 的 对 应 关系 ， 具 体 设 置 是 在 C:\windows\system32\drivers\etc\hosts 文 件 中 ,设置 的 格式 是 “IP+ 空 格 + 域名 ”,， 一行 一 条 记录 (空格 可 以 有 多 个 ) ， 比 如 下 面 的 
设置 : 


127:0.0.1 localhost 
T2701 Www. test .com 
123.123.123.123www.123.com 


第 一 行 是 将 localhost 设 置 到 了 本 机 ， 所 以 平时 使 用 localhost 就 可 以 访问 本 机 了 ， 第 二 行 是 将 www.test.com 设 置 到 了 本 机 ， 第 三 行 是 将 www.123.com 设 置 到 了 123.123.123.123 地 址 。 


本 机 在 解析 域名 时 首先 会 从 hosts 文 件 中 查找 ， 如 果 可 以 查找 到 就 直接 使 用 ， 如 果 找 不 到 才 会 从 DNS 服 务 器 获取 。 正 常 在 做 测试 的 时 候 可 以 使 用 hosts 文 件 的 设置 来 模拟 实际 主机 ， 不 过 hosts 文 件 也 可 能 


会 被 恶意 程序 修改 ， 这 种 情况 可 能 会 带 来 严重 的 后 果 ， 比 如 ， 将 www.taobao.com 指 向 一 个 钓鱼 网 站 ， 这 时 在 访问 淘宝 时 实际 就 会 访问 到 钓鱼 网 站 ， 而 且 看 域名 也 没有 问题 。 在 Windows 7 中 hosts 文 件 默 
认 是 只 读 文 件 。 


第 4 章 Java 中 Socket 的 用 法 


本 章 介绍 Java 中 Socket 的 用 法 ，Java 中 的 Socket 可 以 分 为 普通 Socket 和 NioSocket 两 种 。 


4.1 普通 Socket 的 用 法 


Java 中 的 网 络 通信 征 通过 Socket 实 现 的 ，Socket 分 为 ServerSocket 和 Socket 两 大 类 ，ServerSocket 用 于 服务 端 ， 可 以 通过 accept 方 法 监听 请 求 ， 监 听 到 请 求 后 返回 Socket，Socket 用 于 具体 完成 数 
传输 ， 客 户 端 直接 使 用 Socket 发 起 请 求 并 传输 数据 。 


ServerSocket 的 使 用 可 以 分 为 三 步 : 


1) 创建 ServerSocket。ServerSocket 的 构造 方法 一 共有 5 个 ， 用 起 来 最 方便 的 是 Server-Socket (int port) ， 只 需要 一 个 port (端口 号 ) 就 可 以 了 。 


创建 出 来 的 ServerSocket 的 accept 方 法 进行 监听 。accept 方 法 是 阻塞 方法 ， 也 就 是 说 调 


2) 调 

accept 方 法 会 返回 一 个 Socket。 
3) 使 用 accept 方 法 返回 的 Socket 与 客户 端 进行 通信 。 
下 面 写 一 个 ServerSocket 简 单 的 使 用 示例 。 


控制 台 


可 ， 


出 


import java.io.*; 


import java.net.ServerSocket; 


import java.net.Socket; 
public class Server { 
public static void 
try { 


main (String args[]) { 


// 创 建 一 个 ServerSocket 监 听 8080 端 口 
ServerSocket server = new ServerSocket (8080); 


// 等 待 请 求 


Socket SOSket = server.accel Ee 


// 接 收 到 请 求 后 使 用 socket 进 行 通信 ， 


创建 BufferedReader 用 于 


accept 方 法 后 程序 会 停 下 来 等 待 连 : 


读 取 数 据 ， 


BufferedReader is = new BufferedReader (new InputStreamReader (socket.getInputStream() ) ) 7 
String line = is.readLine(); 


System.out. 


// 创 建 Printi 


println("received from client: " + line); 


Writer， 用 于 发 送 数据 


PrintWriter pw = new PrintWriter (socket .getOutputStream()); 


pw.println("received data: 


pw.flush(); 
// 关 闭 资 源 


"+ line); 


pw.close(); 
is.close(); 
socket.close(); 
server.close(); 

} catch (Exception e) { 
e.printstackTrace (); 


} 


H 


+ 四 


在 上 面 的 Server 里 
， 再 将 数据 发 送 到 


client, 


建 了 ServerSocket， 然 后 调 上 


先 创 


accept 等 待 请 求 ， 当 接收 到 请 求 后 ，F 


来 看 客 
的 过 程 衣 


然后 F 
Socket 创 建 


下 面 看 个 简单 的 示例 。 


import java.io.*; 


户 端 Socket 的 F 
会 跟 服务 端 建立 连 : 


法 。Socket 的 使 
， 创 建 完 Socket 后 ， 再 | 


import java.net.Socket; 


public class Client { 


public static void main (String args[]) { 


String msg = 
try { 
// 创 建 一 个 S 


Socket socket = new Socket ("127.0.0.1", 


"Client Data"; 


ocket， 跟 本 机 的 8080 端 口 连 接 
8080); 


告诉 client 接 收 到 的 是 什么 数据 ， 功 能 非常 简单 。 


也 一 样 ， 首 先 创建 一 个 Socket，Socket 的 构造 方法 非常 多 ， 这 
其 创建 Writer 和 Reader 来 传输 数据 ， 数 据 传输 完成 后 释放 资源 关闭 连接 就 可 以 了 。 


// 使 用 Socket 创 建 PrintWriter 和 BufferedReader 进 行 读 写 数 据 
PrintWriter pw = new PrintWriter (Socket.getOutputStream() ) 7 
BufferedReader is = new BufferedReader (new InputStreamReader (socket.getInputStream())); 


// 发 送 数 据 


pw.println (msg); 
pw.flush(); 


/ /接收 数据 


String line = is.readLine(); 


System.out.println("received from server: " 


// 关 闭 资源 


pw.close(); 
is.close(); 


socket .close(); 
} catch (Exception e) { 
e.printstackTrace (); 


} 


+ line); 


功能 也 非常 简单 ， 启 动 后 自动 将 msg 发 送 给 服务 端 ， 然 后 再 接收 服务 端 返回 的 数据 并 打印 到 控制 台 ， 最 后 释放 资源 关闭 连接 。 
先 启动 Server 然 后 启动 Client 就 可 以 完成 一 次 通信 。 我 们 这 里 只 是 为 了 说 明 原 理 ， 所 以 功能 非常 简单 ， 最 后 Server 端 的 控制 台 输 出 


“received from server:received data: Client Data” 


4.2 ”NioSocket 的 用 法 


ServerSocketChannel 和 SocketChannel, 


多 起 来 的 时 候 这 种 模式 就 应 付 不 过 来 了 ， 如 果 现 在 的 电 商 网 站 也 用 这 种 配送 方式 ， 效 果 大 家 可 想 而 知 ， 所 以 电 商 网 站 必须 采 
一 起 拿 去 送 ， 而 且 在 中 转 站 都 有 专门 的 分 拣 员 负责 按 配送 范围 把 货物 分 给 不 同 的 送 货 员 ， 


递 并 不 会 一 件 一 件 地 送 ， 而 是 将 很 多 件 货 
式 ，Buffer 就 是 所 要 送 的 货物 ，Channel 就 是 这 


求 ， 那 还 是 原来 的 处 理 模式 ,一 


co 


方法 有 一 个 long 类 型 的 参数 ， 
重 载 方法 ，select 方 法 会 采 


从 JDK1.4 开 始 ， 


要 想 理解 NioSocket 的 使 用 必须 先 理解 三 个 
而 且 提 供 送 货 上 门 的 服务 ， 只 要 公 


Java 增 加 了 新 的 io 模 式 一 一 nio (new IO0) ，nio 在 底 
它们 分 别 对 应 原来 的 ServerSocket 和 


里 用 的 是 Socket (String host,int port) ， 把 


“received from client:Client Data” ， 


标 主机 的 地 址 和 端口 号 传 入 即 


Client 端 控制 台 输 


概念 : Buffer、Channel 和 


及 


富里 有 打 电 话 买 东西 ， 他 就 送 过 去 、 收 钱 、 返 


了 新 的 处 理 方式 ， 极 大 地 提高 了 IO 的 效率 。 我 们 使 
Socket。 


的 Socket 也 


属于 IO 的 一 种 ，nio 提 供 了 相应 的 工 


请 求 ， 在 接收 到 请 求 之 前 程序 将 不 会 往 下 走 ， 当 接收 到 请 求 后 


的 Socket 创 建 Reader 和 Writer 来 接收 和 发 送 数 据 ，Reader 接 收 到 数据 后 保存 到 line， 然 后 打印 到 


Selector。 为 了 方便 大 家 理解 ， 我 们 来 看 个 例子 。 记 得 我 上 学 的 时 候 有 个 同学 批发 了 很 多 方便 | 
这 种 模式 就 相当 于 普通 Socket 处 理 请 求 的 模式 。 如 果 请 求 不 是 很 多 ， 
新 的 配送 模式 ， 这 就 是 现在 快递 的 模式 (也 许 以 后 还 


回来 ， 然 后 再 等 下 一 个 电话 ， 


面 、 电 话 卡 和 别 的 日 


货 员 (或 者 


往 某 个 


区 域 的 配 货车 ) ，Selector 就 是 中 转 站 的 分 拣 员 。 


NioSocket 使 用 中 首先 要 创建 ServerSocketChannel， 然 后 注册 Selector， 接 下 来 就 可 以 用 Selector 接 收 请 求 并 处 理 了 。 


ServerSocketChannel 可 以 使 有 


nfigureBlocking (false) 


般 使 用 获取 到 的 ServerSocket 来 绑 定 端口 。ServerSocketChannel 可 以 通过 configureBlocking 方 法 来 设置 是 否 采 

来 设置 ， 设 置 了 非 阻塞 模式 之 后 就 可 以 调用 register 方 法 注册 selector 来 使 用 了 (阻塞 模式 不 可 以 使 用 Selector) 。 
Selector 可 以 通过 其 静态 工厂 方法 open 创 建 ， 创 建 后 通过 Channel 的 register 方 法 注册 到 ServerSocketChanne| 或 者 SocketChannel 上 ， 注 册 
代表 最 长 等 待 时 间 ， 如 果 在 这 段 时 间 里 接收 到 了 相应 操作 的 请 求 则 返回 可 以 处 理 的 请 求 的 数量 ， 否 则 在 超时 后 返回 


己 的 静态 工厂 方法 open 创 建 。 每 个 ServerSocketChannel 对 应 一 个 ServerSocket， 


可 以 调 


这 样 效 率 就 提高 了 很 多 。 这 种 模式 就 相当 于 NioSocket 的 处 


非 阻塞 模式 可 以 


阻塞 模式 ， 如 果 要 采 


阻塞 模式 直到 有 相应 操作 的 请 求 出 现 。 


当 接 收 到 请 求 


selectedKeys 方 法 返回 SelectionKey 的 集合 。 


于 Selector 调 上 


0， 程 序 继续 往 下 走 ， 如 果 传 入 的 参数 为 0 或 者 调 


品 在 宿舍 卖 ， 
这 是 没有 问题 的 ， 当 请 求 
还 会 有 更 合理 的 模式 ) 。 
理 模 


快 


其 socket 方 法 来 获取 ， 不 过 如 果 直 接 使 用 获取 到 ServerSocket 来 监听 请 


内 完 之 后 Selector 就 可 以 通过 select 方 法 来 等 待 请 求 ，select 


无 参数 的 


SelectionKey 保 存 了 处 理 当 前 请 求 的 Channel 和 Selector， 并 且 提 供 了 不 同 的 操作 类 型 。Channel 在 注册 Selector 的 时 候 可 以 通过 register 的 第 二 个 参数 选择 特定 的 操作 ， 这 里 的 操作 就 是 在 
SelectionKey 中 定义 的 ,一 共有 4 种 : 


* SelectionKey.OP_ACCEPT 

* SelectionKey.OP_CONNECT 
* SelectionKey.OP_READ 

* SelectionKey.OP_WRITE 


它们 分 别 表示 接受 请 求 操 作 、 连 接 操作 、 读 操作 和 写 操作 ， 只 有 在 register 方 法 中 注册 了 相应 的 操作 Selector 才 会 关心 相应 类 型 操作 的 请 求 。 


Channel 和 Selector 并 没有 谁 属于 谁 的 关系 ， 就 好 像 一 个 分 拣 员 可 以 为 多 个 地 区 分 拣 货 物 而 每 个 地 区 也 可 以 有 多 个 分 拣 员 来 分 拣 一 样 ， 它 们 就 好 像 数 据 库 里 的 多 对 多 的 关系 ， 不 过 Selector 这 个 分 拣 员 分 
拣 得 更 细 ， 它 可 以 按 不 同 的 类 型 来 分 拣 ， 分 拣 后 的 结果 保存 在 Selec-tionKey 中 ， 可 以 分 别 通过 SelectionKey 的 channe| 方 法 和 selector 方 法 来 获取 对 应 的 Channel 和 Selector， 而 且 还 可 以 通过 
isAcceptable、isConnectable、isReadable 和 isWritable 方 法 来 判断 是 什么 类 型 的 操作 。 


NioSocket 中 服务 端的 处 理 过 程 可 以 分 为 5 步 : 


| 


创建 ServerSocketChannel 并 设置 相应 参数 。 


2) 创建 selector 并 注册 到 ServerSocketChannel 上 。 


3) 调用 Selector 的 select 方 法 等 待 请 求 。 


4) Selector 接 收 到 请 求 后 使 用 selectedKeys 返 回 SelectionKey 集 合 。 


5) 使 用 SelectionKey 获 取 到 Channel、Selector 和 操作 类 型 并 进行 具体 操作 。 


我 们 来 写 个 例子 将 前 面 的 Server 改 成 使 用 nio 方 式 进行 处 理 的 NIOServer。 


import java.io.IOException; 
import java.net.InetSocketAddress; 
import java.nio.ByteBuffer; 
import java.nio.channels.SelectionKey; 
import java.nio.channels.Selector; 
import java.nio.channels.ServerSocketChannel; 
import java.nio.channels.SocketChannel; 
import java.nio.charset.Charset; 
import java.util.Iterator; 
public class NIOServer { 
public static void main (String[] args) throws Exception{ 
// 创 建 ServerSocketChanne1， 监 听 8080 端 口 
ServerSocketChannel ssc=ServerSocketChannel .open(); 
ssc.socket () .bind (new InetSocketAddress (8080)); 
// 设 置 为 非 阻塞 模式 
ssc.configureBlocking (false); 
// 为 ssc 注 册 选 择 器 
Selector selector=Selector.open (); 
ssc.register(selector, SelectionKey.OP ACCEPT); 
// 创 建 处 理 器 
Handler handler = new Handler (1024); 
while (true){ 
// 等 待 请 求 ， 每 次 等 待 阻塞 3s， 超 过 3s 后 线程 继续 向 下 运行 ， 如 果 传 入 0 或 者 不 传 参数 将 一 
// 直 阻 塞 
if(selector.select (3000)==0){ 
System.out .println ("等 待 请 求 超时 ……"); 
continue; 
ls 
System.out .println ("处 理 请 求 ……"); 
// 获取 待 处 理 的 SelectionKey 
Iterator<SelectionKey> keyIter=selector.selectedKeys () .iterator (); 
while (keyIter.hasNext () ) { 
SelectionKey key=keyIter.next () 7 
try{ 
// 接收 到 连接 请 求 时 
if (key.isAcceptable()){ 
handler .handleAccept (key); 


} 

// 读数 据 

if (key.isReadable()){ 
handler .handleRead (key); 


} catch (IOException ex) { 
keyIter.remove (); 
continue; 


i 
// 处 理 完 后 ， 从 待 处 理 的 SelectionKey 夫 代 器 中 移 除 当前 所 使 用 的 key 


keyIter.remove (); 


} 
} 
private static class Handler { 
private int bufferSize = 1024; 
private String localCharset = "UTF-8"; 
public Handler () {} 
public Handler (int buffersize){ 
this (bufferSize, null); 


} 
Public Handler(String LocalCharset){ 
this(-1, LocalCharset); 
} 
public Handler (int bufferSsize, String localCharset){ 
if (bufferSize>0) 
this.bufferSize=pbufferSize; 
if(localCharset!=null) 
this.localCharset=localCharset; 


} 
public void handleAccept (SelectionKey key) throws IOException { 
SocketChannel sc= ( (ServerSocketChanne1) key.channel ()) .accept (); 
sc.configureBlocking (false); 
sc.register (key.selector(), SelectionKey.OP READ, ByteBuffer.allocate (bufferSize)); 
} 
public void handleRead (SelectionKey key) throws IOException { 
// 获取 channel 
SocketChannel sc=(SocketChannel) key.channel (); 
// 获取 buffer 并 重 置 
ByteBuffer buffer=(ByteBuffer) key.attachment (); 
buffer.clear (); 
// 没有 读 到 内 容 则 关闭 
ifl(sc.read (buffer)=—-1){ 
sc.close(); 
} else { // 将 buffer 转 换 为 读 状态 
buffer.flip(); 
// 将 buffer 中 接收 到 的 值 按 localCharset 格 式 编码 后 保存 到 receivedString 
String receivedString = Charset.forName (localCharset) .newDecoder (). decode (buffer) .toString () 7 
System.out .println("received from client: " + receivedSstring); 
// 返回 数据 给 客户 端 


String sendString = "received data: " + receivedString; 
buffer = ByteBuffer.wrap (sendString.getBytes (localCharset)); 
sc.write (buffer); 

// 关闭 Socket 

sc.close(); 


上 面 的 处 理 过 程 都 做 了 注释 ，main 方 法 启动 监听 ， 当 监听 到 请 求 时 根据 SelectionKey 的 状态 交 给 内 部 类 Handler 进 行 处 理 ，Handler 可 以 通过 重 载 的 构造 方法 设置 编码 格式 和 每 次 读 取 数据 的 最 大 值 。 
Handler 处 理 过 程 中 用 到 了 Buffer，Buffer 是 java.nio 包 中 的 一 个 类 ， 专 门 用 于 存储 数据 ，Buffer 里 有 4 个 属性 非常 重要 ， 它 们 分 别 是 : 


' capacity: 容量 ， 也 就 是 Buffer 最 多 可 以 保存 元 素 的 数量 ， 在 创建 时 设置 ， 使 用 过 程 中 不 可 以 改变 ; 


“ limit: 可 以 使 用 的 上 限 ， 开 始 创建 时 limit 和 capacity 的 值 相同 ， 如 果 给 limit 设 置 一 个 值 之 后 ，limit 就 成 了 最 大 可 以 访问 的 值 ， 其 值 不 可 以 超过 capacity。 比 如 ， 一 个 Buffer 的 容量 capacity 为 100， 表 示 最 多 可 
以 保存 100 个 数据 ， 但 是 现在 只 往 里 面 写 了 20 个 数据 然后 要 读 取 ， 在 读 取 的 时 候 limit 就 会 设置 为 20; 


“ position: 当前 所 操作 元 素 所 在 的 索引 位 置 ，position 从 0 开始 ， 随 着 get 和 put 方 法 自动 更 新 ; 


“ matk: 用 来 暂时 保存 position 的 值 ，position 保 存 到 matk 后 就 可 以 修改 并 进行 相关 的 操作 ， 操 作 完 后 可 以 通过 reset 方 法 将 matk 的 值 恢复 到 position。 比 如 ，Buffer 中 一 共 保 存 了 20 个 数据 ，position 的 位 置 是 
10， 现 在 想 读 取 15 到 20 之 间 的 数据 ， 这 时 就 可 以 调用 Buffer#mark0 将 当前 的 position 保 存 到 matk 中 ， 然 后 调用 Buffer#position (15) 将 position 指 向 第 15 个 元 素 ， 这 时 就 可 以 读 取 了 ， 读 取 完 之 后 调用 
Buffer#reset0 就 可 以 将 Position 恢复 到 10。mark 默 认 值 为 -1 ， 而 且 其 值 必 须 小 于 position 的 值 ， 如 果 调 用 Buffetr#position (int newPosition) 时 传 入 的 newPosition 比 mark 小 则 会 将 mark 设 为 -1。 


这 4 个 属性 的 大 小 关系 是 : mark< =position< =limit<=capacity。 


理解 了 这 4 个 属性 ，Buffer 就 容易 理解 了 。 我 们 这 里 的 NioServer 用 到 clear 和 flip 方 法 ，clear 的 作用 是 重新 初始 化 limit、position 和 mark 三 个 属性 ， 让 limit=capacity、position=0、mark=-1。flip 方 
法 的 作用 是 这 样 的 : 在 保存 数据 时 保存 一 个 数据 position 加 1， 保 存 完了 之 后 如 果 想 读 出 来 就 需要 将 最 好 position 的 位 置 设置 给 limit， 然 后 将 position 设 置 为 0%， 这 样 就 可 以 读 取 所 保存 的 数据 了 ，flip 方 法 就 
是 做 这 个 用 的 ， 这 两 个 方法 的 代码 如 下 : 


// java.nio.Buffer 

public final Buffer clear() { 
position = 0; 
limit = capacity; 
mark = -1; 
return this; 

} 

public final Buffer flip() { 
limit = position; 
position = 0; 
mark = -1; 
return this; 


NioSocket 就 介绍 到 这 里 ， 当 然 我 们 所 举 的 例子 只 是 为 了 让 大 家 理解 NioSocket 使 用 的 方法 ， 实 际 使 用 中 一 般 都 会 采用 多 线程 的 方式 来 处 理 ， 不 过 使 用 单线 程 更 容易 理解 ， 第 5 章 将 会 把 这 里 的 例子 改 成 
多 线程 ， 在 后 面 分 析 Tomcat 的 时 候 大 家 可 以 看 到 实际 的 用 法 。 


第 5 章 自己 动手 实现 HTTP 协 议 


我 们 知道 HTTP 协 议 是 在 应 用 层 解析 内 容 的 ， 只 需要 按照 它 的 报 文 的 格式 封装 和 解析 数据 就 可 以 了 ， 具 体 的 传输 还 是 使 用 的 Socket， 在 第 4 章 NioServer 的 基础 上 自己 做 一 个 简单 的 实现 了 HTTP 协 议 的 例 
Ts 


因为 HTTP 协 议 是 在 接收 到 数据 之 后 才 会 用 到 的 ， 所 以 我 们 只 需要 修改 NioServer 中 的 Handler 就 可 以 了 ， 在 修改 后 的 HttpHandler 中 首先 获取 到 请 求 报 文 并 打印 出 报 文 的 头 部 (包含 首 行 ) 、 请 求 的 方 
法 类 型 、Url 和 Http 版 本 ， 最 后 将 接收 到 的 请 求 报 文 信息 封装 到 响应 报 文 的 主体 中 返回 给 客户 端 。 这 里 的 HttpHandler 使 用 了 单独 的 线程 来 执行 ， 而 且 把 SelectionKey 中 操作 类 型 的 选择 也 放 在 了 
HttpHandler 中 ， 不 过 具体 处 理 过 程 和 前 面 的 NioServer 没 有 太 大 的 区 别 ， 代 码 如 下 : 


import java.io.IOException; 
import java.net.InetSocketAddress; 
import java.nio.ByteBuffer; 
import java.nio.channels.SelectionKey; 
import java.nio.channels.Selector; 
import java.nio.channels.ServerSocketChannel; 
import java.nio.channels.SocketChannel; 
import java.nio.charset.Charset; 
import java.util.Iterator; 
public class HttpServer { 
public static void main (String[] args) throws Exception{ 
// 创 建 ServerSocketChannel， 监 听 8080 端 口 
ServerSocketChannel ssc=ServerSocketChannel .open(); 
ssc.socket () .bind (new InetSocketAddress (8080)); 
// 设 置 为 非 阻塞 模式 
ssc.configureBlocking (false); 
// 为 SSC 注册 选择 器 
Selector selector=Selector .open (); 
ssc.register (selector, SelectionKey.OP ACCEPT); 
// 创 建 处 理 器 
while (true) { 
// 等 待 请 求 ， 每 次 等 待 阻塞 3s， 超 过 3s 后 线程 继续 向 下 运行 ， 如 果 传 入 0 或 者 不 传 参数 将 一 直 阻 塞 
if(selector.select (3000)==0) { 
continue; 


} 
// 获取 待 处 理 的 SelectionKey 
Iterator<SelectionKey> keyIter=selector.selectedKeys () .iterator (); 
while (keyIter.hasNext () ) { 
SelectionKey key=keyIter.next (); 
// 启动 新 线程 处 理 SelectionKey 
new Thread (new HttpHandler (key) ) .run(); 
// 处 理 完 后 ， 从 待 处 理 的 SelectionKey 和 迭代 器 中 移 除 当前 所 使 用 的 key 


keyIter.remove (); 


} 
} 
private static class HttpHandler implements Runnable{ 
private int bufferSize = 1024; 
private String localCharset = "UTF-8"; 
private SelectionKey key; 
Public HttpHandler (SelectionKey key){ 
this.key = key; 
} 
public void handleAccept () throws IOException { 
SocketChannel clientChannel=( (ServerSocketChannel) key.channel ()) .accept (); 
clientChannel .configureBlocking (false); 
clientChannel .register (key.selector(), SelectionKey.OP READ, ByteBuffer.allocate (bufferSize) ) 7 
bE: 


public void handleRead() throws IOException { 
// 获取 channel 
SocketChannel sc=(SocketChannel) key.channel (); 
// 获取 buffer 并 重 置 
ByteBuffer buffer=(ByteBuffer) key.attachment (); 
buffer.clear (); 
// 没有 读 到 内 容 则 关闭 
if(sc.read (buffer)==-1){ 
sc.close(); 
} else { 
// 接收 请 求 数据 
buffer.flip(); 
String receivedString = Charset.forName (localCharset) .newDecoder () .decode (buffer) .toString (); 
// 控制 台 打 印 请 求 报 文 头 
String[] requestMessage = receivedString.split("\r\n"); 
for (String s: requestMessage){ 
System.out .Println(s) 7 
// 遇 到 空 行 说 明报 文 头 已 经 打印 完 
if(s.isEmpty()) 


break; 
E 
// 控制 台 打印 首 行 信息 
String[] firstLine = requestMessage[0] .split(" "); 


System.out .println(); 
System.out .Println ("Method:\t"+firstLine[0]); 
System.out.println("url:\t"+firstLine[1]); 
System.out .println ("HTTP Version:\t"+firstLine[2]); 
System.out .println(); 
// 返回 客户 端 
StringBuilder sendString = new StringBuilder(); 
sendString.append ("HTTP/1.1 200 OK\r\n");// 响 应 报 文 首 行 ，200 表 示 处 理 成 功 
sendSstring.append ("Content-Type:text/html;charset=" + localCharset+"\r\n"); 
sendString.append("\r\n");// 报 文 头 结束 后 加 一 个 空 行 
sendString.append ("<html><head><title> 显 示 报 文 </title></head><body>"); 
sendString.append ("接收 到 请 求 报 文 是 : <br/>"); 
for (String s: requestMessage){ 
sendSstring.append(s + "<br/>"); 
} 
sendSstring.append ("</body></html>"); 
buffer = ByteBuffer.wrap (sendString.toString() .getBytes (localCharset)); 
sc.write (buffer); 
sc.close(); 
i 
} 
QOverride 
public void run() { 


tet{ 
// 接收 到 连接 请 求 时 
if (key.isAcceptable()){ 
handleAccept (); 


} 

// 读数 据 

if (key.isReadable()){ 
handleRead (); 


} 
} catch (IOException ex) { 
ex.printStackTrace (); 
} 


整个 过 程 非常 简单 ， 按 照 报 文 的 格式 来 读 取 和 发 送 就 可 以 了 ， 接 收 到 数据 后 按 “^r\n” 分 割 成 每 一 行 ， 在 空 行 之 前 都 是 报 文 头 (包含 首 行 )， 空 行 下 面 如 果 有 内 容 就 是 报 文 的 主体 ， 因 为 这 里 是 Get 请 求 
所 以 就 没有 主体 了 ， 首 行使 用 空格 分 割 后 可 以 得 到 请 求 的 方法 、Url 和 Http 的 版 本 ， 如 果 需 要 请 求 头 的 值 只 需要 把 头 部 的 每 一 行 用 冒号 分 割 开 就 行 了 。 下 面 就 来 看 一 下 运行 效果 ， 首 先 启动 程序 ， 然 后 在 浏览 
器 中 输入 http://localhost:8080/ 发 起 请 求 ， 这 时 控制 台 就 会 打印 出 如 下 信息 (不 同 的 环境 打印 的 结果 会 不 同 ) 。 


GET / HTTP/1.1 

Host: localhost:8080 

Connection: keep-alive 

Cache-Control: max-age=0 

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp, */*;q=0.8 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.76 Safari/537.36 
Accept-Encoding: gzip,deflate, sdch 

Accept-Language: zh-CN,zh;q=0.8,en;q=0.6 

Method: GET 

Wls / 

HTTP Version: HTTP/1.1 


浏览 器 显示 结果 如 图 5-1 所 示 。 


BR PP PP PP 


和 了 了 了 GDlocalhost'8080 


接收 到 请 求 报 文 是 ， 
GET / HTTP/1.1 
Host: localhost:8080 


Connection: keep-alive 

Cache-Control: max-age=0 

Accept: text/html, application/xhtml+xml, application/xml; q=0. 9, image/webp, */+*; q=0.8 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537. 36 (KHTNL, like 
Gecko) Chrome/32.0.1700.76 Safari/537.36 

Accept -Encoding: gzip, deflate, sdch 

Accept-Language: zh-CN, zh; q=0. 8, en; q=0.6 


图 5-1 浏览 器 显示 结果 


这 里 也 只 是 一 个 简单 的 示例 ， 目 的 是 让 大 家 了 解 HTTP 协 议 的 实现 方法 ， 这 里 的 功能 还 不 够 完善 ， 它 并 不 能 真正 处 理 请 求 ， 实 际 处 理 中 应 该 根据 不 同 的 Url 和 不 同 的 请 求 方法 进行 不 同 的 处 理 并 返回 不 同 
的 响应 报 文 ， 另 外 这 里 的 请 求 报 文 也 必须 在 bufferSize (1024) 范围 内 ， 如 果 太 长 就 会 接收 不 全 ， 而 且 也 不 能 返回 图 片 等 流 类 型 的 数据 ( 流 类 型 只 需要 在 响应 报 文 中 写 清楚 Content-Type 的 类 型 ， 并 将 相应 
数据 写 入 报 文 的 主体 就 可 以 了 ) ， 不 过 对 于 了 解 HTTP 协 议 实现 的 方法 已 经 够 用 了 。 


第 6 章 ”详解 Servlet 


Servlet 是 server+Applet 的 缩写 ， 表 示 一 个 服务 器 应 用 。 通 过 上 面 的 分 析 我 们 知道 Servlet 其 实 就 是 一 套 规范 ， 我 们 按照 这 套 规 范 写 的 代码 就 可 以 直接 在 Java 的 服务 器 上 面 运行 。Servlet3.1 中 Servlet 的 


结构 如 图 6-1 所 示 。 


GenericServlet 


(© HttpServlvt 


图 6-1 Servlet3.1 中 的 Servlet 结 构图 


6.1 Servlet 接 口 


既然 Servlet 是 一 套 规范 ， 那 么 最 重要 的 当然 就 是 接口 了 。Servlet3.1 中 Servlet 的 接口 定义 如 下 : 


// javax.servlet.Servlet 
public interface Servlet { 
public void init(ServletConfig config) throws ServletException; 
Public ServletConfig getServletConfig(); 
public void service (ServletRequest req, ServletResponse res) 
throws ServletException, IOException; 
Public String getServletInfo(); 
Public void destroy(); 


init 方 法 在 容器 启动 时 被 容器 调用 ( 当 load-on-startup 设 置 为 负数 或 者 不 设置 时 会 在 Servlet 第 一 次 


解 ServletConfig; service 方 法 用 于 具体 处 理 一 个 请 求 ; getServletlnfo 方 法 可 以 获取 一 些 Servlet 相 关 的 信息 ， 如 作者 、 版 权 等 ， 这 个 方法 需要 自己 实现 ， 默 认 返 回 空 字 符 串 ; destroy 主 要 


毁 (一 般 指 关 闭 服务 器 ) 时 释放 一 些 资源 ， 也 只 会 调用 一 次 。 


到 时 才 被 调 


) ， 只 会 调 


一 次 ; getServletConfig 方 法 有 


于 获取 ServletConfig,， 


在 下 面 会 详细 讲 


Init 方 法 被 调用 时 会 接收 到 一 个 servletConfig 类 型 的 参数 ， 是 容器 传 进去 的 。Servlet-Config 顾 名 思 义 指 的 是 Servlet 的 配置 ， 我 们 在 web.xml 中 定义 Servlet 时 通过 init-param 标 签 配置 
ServletConfig 来 保存 的 ， 比 如 ,定义 Spring MVC 的 Servlet 时 指定 配置 文件 位 置 的 contextConfigLocation 参 数 就 保存 在 ServletConfig 中 ， 例 如 下 面 的 配置 : 


<servlet> 
<servlet-name>demoDispatcher</servlet-name> 
<servlet-class>org.springframework.web.servlet .DispatcherServlet</servlet-class> 
<init-param> 
<param-name>contextConfigLocation</param-name> 
<param-value>demo-servlet .xml</param-value> 
</init-param> 


于 在 Servlet 销 


<load-on-startup>1</1Load-on-startup> 
</servlet> 


状 


Tomcat 中 Servlet 的 init 方 法 是 在 org.apache.catalina.core.StandardWrapper 的 initServlet 方 法 中 调用 的 ，ServletConfig 传 入 的 是 StandardWrapper (里 面 封装 着 Servlet) 自身 的 门 
StandardWrapperFacade。 其 实 这 个 也 很 容易 理解 ，Servlet 是 通过 xml 文 件 配置 的 ， 在 解析 xml 时 就 会 把 配置 参数 给 设置 进去 ， 这 样 StandardWrapper 本 身 就 包含 配置 项 了 ， 当 然 ， 并 不 是 


StandardWrapper 的 所 有 内 容 都 是 Config 相 关 的 ， 所 以 就 用 了 其 门面 Facade 类 。 下 面 是 ServletConfig 接 口 的 定义 : 


package javax.servlet; 
import java.util.Enumeration; 
public interface ServletConfig { 
public String getServletName (); 
public ServletContext getServletContext (); 
public String getInitParameter (String name); 
public Enumeration<String> getInitParameterNames () ; 


获取 Servlet 的 名 字 ， 也 就 是 我 们 在 web.xml 中 定义 的 servlet-name; getlnitParameter 方 法 用 于 获取 init-param 配 置 的 参数 ; getlnitParameterNames 用 于 获取 配置 的 所 有 init- 
本 身 ， 如 果 你 看 了 前 面 Tomcat 的 分 析 就 会 想到 ，ServletContext 其 实 就 是 Tomcat 中 Context 的 门面 类 


getServletName 用 于 
param 的 名 字 集 合 ;getServletContext 非 常 重要 ， 它 的 返回 值 ServletContext 代 表 的 是 我 们 这 个 应 | 
ApplicationContextFacade (具体 代码 参考 StandardContext 的 getServletContext 方 法 ) 。 既 然 ServletContext 代 表 应 用 本 身 ， 那 么 ServletContext 里 边 设置 的 参数 就 可 以 被 当前 应 用 的 所 有 Servlet 共 享 


了 。 我 们 做 项 目的 时 候 都 知道 参数 可 以 保存 在 session 中 ， 也 可 以 保存 在 Application 中 ， 而 后 者 很 多 时 候 就 是 保存 在 了 ServletContext 中 。 


我 们 可 以 这 么 理解 ，ServletConfig 是 Servlet 级 的 ， 而 ServletContext 是 Context (也 就 是 Application) 级 的 。 当 然 ，ServletContext 的 功能 要 强大 很 多 ， 并 不 只 是 保存 一 下 配置 参数 ， 否 则 就 叫 


ServletContextConfig 了 。 


实 还 真有 ， 在 ServletContext 接 口中 有 这 么 一 个 方 


null， 如 果 想 使 用 需要 进行 一 些 设 


有 的 读者 可 能 会 想 ，Servlet 级 和 Context 级 都 可 以 操作 ， 那 有 没有 更 高 一 层 的 站 点 级 也 就 是 Tomcat 中 的 Host 级 的 相应 操作 呢 ? 在 Servlet 的 标准 里 
法 : public ServletContext getContext (String uripath) ， 它 可 以 根据 路 径 获取 到 同一 个 站 点 下 的 别 的 应 用 的 ServletContext! 当然 由 于 安全 的 原因 ， 一 般 会 返 


回 


ServletConfig 和 ServletContext 最 常见 的 使 用 之 一 是 传递 初始 化 参数 。 我 们 就 以 spring 配 置 中 使 用 得 最 多 的 contextConfigLocation 参 数 为 例 来 看 一 下 : 


<!--web.xml--> 
<?xml Version="1.0" encoding="UTF-8"?> 
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" 
Version="3.1" 
metadata-complete="true"> 
<display-name>initParam Demo</display-name> 
<context-param> 
<param-name>contextConfigLocation</param-name> 
<param-value>application-context .xml </param-value> 
</context-param> 
<servlet> 
<servlet-name>DemoServlet</servlet-name> 
<servlet-class>com.excelib.DemoServlet</servlet-class> 
<init-param> 
<param-name>contextConfigLocation</param-name> 
<param-value>demo-servlet .xml</param-value> 
</init-param> 
</servlet> 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/15447/0EBPS/Text/. .http://www.hzcourse.com/resource/readBook?path=/openresources/teac 


</web-app> 


上 面 通 过 context-param 配 置 的 contextConfigLocation 配 置 到 了 ServletContext 中 ， 而 通过 servlet 下 的 init-param 配 置 的 contextConfigLocation 配 置 到 了 ServletConfig 中 。 在 Servlet 中 可 以 分 别 通 


过 它们 的 getInitParameter 方 法 进行 获取 ， 比 如 : 


String contextLocation = getServletConfig() .getServletContext () .getInitParameter ("contextConfigLocation"); 
String servletLocation = getServletConfig() .getInitParameter ("contextConfigLocation"); 


为 了 操作 方便 ，GenericServlet 定 义 了 getlnitParameter 方 法 ， 内 部 返回 getServletConfig().getlnitParameter 的 返回 值 ， 因 此 ， 我 们 如 果 需 要 获取 ServletConfig 中 的 参数 ， 可 以 不 再 调用 


getServletConfig()， 而 直接 调用 getlnitParameter。 


另外 ServletContext 中 非常 常用 的 用 法 就 是 保存 Application 级 的 属性 ， 这 个 可 以 使 用 setAttribute 来 完成 ， 比 如 : 


getServletContext () .setAttribute ("contextConfigLocation", "new path"); 


需要 注意 的 是 ， 这 里 设置 的 同名 Attribute 并 不 会 覆盖 initParameter 中 的 参数 值 ， 它 们 是 两 套数 据 ， 互 不 干扰 。ServletConfig 不 可 以 设置 属性 。 


而 


6.2 GenericServlet 


GenericServlet 是 Servlet 的 默认 实现 ， 做 了 三 件 事 : @@ 实 现 了 ServletConfig 接 口 ， 我 们 可 以 直接 调用 ServletConfig 里 面 的 方法 ; @ 提 供 了 无 参 的 init 方 法 ; @ 提 供 了 log 方 法 。 


GenericServlet 实 现 了 ServletConfig 接 口 ， 我 们 在 需要 调用 ServletConfig 中 方法 的 时 候 可 以 直接 调用 ， 而 不 再 需要 先 获取 ServletConfig 了 ， 比 如 ， 获 取 ServletContext 的 时 候 可 以 直接 调用 
实 是 在 内 部 调用 了 。getServletContext 的 代码 如 下 : 


底层 实现 


getServletContext， 而 无 须 调 用 getServletConfig().getServletContext(0 了 ， 不 过 


// javax.servlet.GenericServlet 
public ServletContext getServletContext() { 
ServletConfig sc = getServletConfig(); 
if (sc == null) { 
throw new IllegalStateException( 
lStrings.getString ("err.servlet config not initialized")); 
} 


return sc.getServletContext (); 


GenericServlet 实 现 了 Servlet 的 init (ServletConfig config) 方法 ， 在 里 面 将 config 设 置 给 了 内 部 变量 config， 然 后 调用 了 无 参 的 init( 方 法 ， 这 个 方法 是 个 模板 方法 ， 在 子 类 中 可 以 通过 覆盖 它 来 完成 
自己 的 初始 化 工作 ， 代 码 如 下 : 


// javax.servlet.GenericServlet 

public void init (ServletConfig config) throws ServletException { 
this.config = config; 
thiss Lalit(y.» 


Public void init() throws ServletException { 
} 


这 种 做 法 有 三 个 作用 : 首先 ， 将 参数 config 设 置 给 了 内 部 属性 config， 这 样 就 可 以 在 ServletConfig 的 接口 方法 中 直接 调用 config 的 相应 方法 来 执行 ， 其 次 ， 这 么 做 之 后 我 们 在 写 Servlet 的 时 候 就 可 以 只 


处 理 自己 的 初始 化 逻辑 ， 而 不 需要 再 关心 config 了 ; 还 有 一 个 作用 就 是 在 重 写 init 方 法 时 也 不 需要 再 调用 super.init (config) 了 。 如 果 在 自己 的 Servlet 中 重 写 了 带 参数 的 init 方 法 ， 那 么 一 定 要 记 着 调 


super.init (config) ， 否 则 这 里 的 config 属 性 就 接收 不 到 值 ， 相 应 的 ServletConfig 接 口 方法 也 就 不 能 执行 了 。 


GenericServlet 提 供 了 2 个 log 方 法 ， 一 个 记录 日 志 ， 一 个 记录 异常 。 具 体 实现 是 通过 传 给 ServletContext 的 日 志 实 现 的 。 


// javax.servlet.GenericServlet 
public void log (String msg) { 
getServletContext () .1og (getServletName() + ": " + msg); 


} 

public void log(String message, Throwable t) { 
getServletContext () .1og (getServletName() + ": " + message, t); 

} 


一 般 我 们 都 有 自己 的 日 志 处 理 方式 ， 所 以 这 个 用 得 不 是 很 多 。 


GenericServlet 是 与 具体 协议 无 关 的 。 


6.3 HttpServlet 


HttpServlet 是 用 HTTP 协 议 实现 的 Servlet 的 基 类 ， 写 Servlet 时 直接 继承 它 就 可 以 了 ， 不 需要 再 从 头 实现 Servlet 接 口 ， 我 们 要 分 析 的 Spring MVC 中 的 DispatcherServlet 就 是 继承 的 HttpServlet。 既 然 


HttpServlet 是 跟 协 议 相关 的 ， 当 然 主 要 关心 的 是 如 何 处 理 请求 了 ， 所 以 HttpServlet 主 要 
HttpServletResponse， 然 后 根据 Http 请 求 的 类 型 不 同 将 请 求 路 由 到 了 不 同 的 处 理 方法 。 代 码 如 下 : 


写 了 service 方 法 。 在 service 方 法 中 首先 将 ServletRequest 和 Servlet-Response 转 换 为 了 HttpServletRequest 和 


// javax.servlet.http.HttpServlet 
public void service (ServletRequest req, ServletResponse res) 
throws ServletException, IOException 
{ 
HttpServletRequest request; 
HttpServletResponse response; 
// 如 果 请 求 类 型 不 相符 ， 则 抛 出 异常 
if (! (req instanceof HttpServletRequest && 
res instanceof HttpServletResponse)) { 
throw new ServletException ("non-HTTP request or response"); 


} 

// 转 摸 request 和 response 的 类 型 

request = (HttpServletRequest) req; 
response = (HttpServletResponse) res; 
// 调 用 http 的 处 理 方法 


service (request, response); 


protected void service (HttpServletRequest req, HttpServletResponse resp) 
throws ServletException, IOException 


// 获 取 请 求 类 型 
String method = req.getMethod () 7 
// 将 不 同 的 请 求 类 型 路 由 到 不 同 的 处 理 方法 
if (method.equals (METHOD GET)) { 
long lastModified = getLastModified (req); 


{ 


if (lastModified == -1) { 
doGet (req, resp); 
} else { 


long ifModifiedSince = req.getDateHeader (HEADER IFMODSINCE); 
if (ifModifiedSince < lastModified) { 
maybeSetLastModified (resp, lastModified); 
doGet (req, resp); 
} else { 
resp.setStatus (HttpServletResponse.SsC_ NOT MODIFIED); 
} 
} 
} else if (method.equals (METHOD HEAD)) { 
long lastModified = getLastModified (req); 
maybeSetLastModified (resp, lastModified); 
doHead (req, resp); 
} else if (method.equals (METHOD POST)) { 
doPost (req, resp); 
} else if (method.equals (METHOD PUT)) { 
doPut (req, resp); 
} else if (method.equals (METHOD DELETE)) { 
doDelete (req, resp); 
} else if (method.equals (METHOD OPTIONS)) { 
dooptions (req, resp); 
} else if (method.equals (METHOD TRACE)) { 
doTrace (req, resp); 
} else { 
String errMsg = lStrings.getString ("http.method not implemented"); 
Object[] errArgs = new Object[1]; 
errArgs[0] = method; 
errMsg = MessageFormat .format (errMsg, errArgs); 
resp.sendError (HttpServletResponse.SsC_ NOT IMPLEMENTED, errMsg); 


体 处 理 方 法 是 doXXX 的 结构 ， 如 最 常用 的 doGet、doPost 就 是 在 这 里 定义 的 。doGet、doPost、doPut 和 doDelete 方 法 都 是 模板 方法 ， 而 且 如 果子 类 没有 实现 将 抛 出 异常 ， 在 调 
对 是 否 过 期 做 了 检查 ， 如 果 没有 过 期 则 直接 返回 304 状 态 码 使 用 缓存 ; doHead 调 用 了 doGet 的 请 求 ， 然 后 返 


回 


doGet 方 法 前 还 


空 body 的 Response; doOptions 和 doTrace 正 常 不 需要 使 用 ， 主 要 是 用 来 做 一 些 调试 工 


作 ，doOptions 返 回 所 有 支持 的 处 理 类 型 的 集合 ， 正 常情 况 下 可 以 禁用 ，doTrace 是 用 来 远程 诊断 服务 器 的 ， 它 会 将 接收 到 的 header 原 封 不 动 地 返回 ， 这 种 做 法 很 可 能 会 被 黑客 利用 ， 存 在 安全 漏洞 ， 所 以 


如 果 不 是 必须 使 用 ， 最 好 禁用 。 由 于 doOptions 和 doTrace 的 功能 非常 固定 ， 所 以 HttpServlet 做 了 默认 的 实现 。doGet 代 码 如 下 (doPost、doPut、doDelete 与 之 类 似 ) : 


// javax.servlet.http.HttpServlet 
protected void doGet (HttpServletRequest req, HttpServletResponse resp) 
throws ServletException, IOException 
{ 
String Protocol = req.getProtocol (); 
String msg = lStrings.getString ("http.method get not_ supported"); 
if (Protocol.endsWith("1.1")) { 
resp.sendError (HttpServletResponse.SsC METHOD NOT ALLOWED, msg); 
} else { 
resp.sendError (HttpServletResponse.SsC BAD REQUEST, msg); 
} 


这 就 是 HttpServlet， 它 主要 将 不 同 的 请 求 方式 路 由 到 了 不 同 的 处 理 方法 。 不 过 Spring-MVC 中 由 于 处 理 思路 不 一 样 ， 又 将 所 有 请 求 合 并 到 了 统一 的 一 个 方法 进行 处 理 ， 在 Spring-MVC 中 再 详细 讲解 。 


第 7 章 Tomcat 分 析 


前 面 已 经 给 大 家 介绍 了 网 站 处 理 请 求 时 所 涉及 的 各 种 协议 和 实现 方法 ， 不 过 之 前 的 实现 只 是 为 了 让 大 家 明白 原理 而 设计 的 简单 示例 程序 ， 本 章 分 析 一 个 实际 环境 中 经 常 使 用 的 具体 的 实现 一 一 


Tomcat。 


7.1 Tomcat 的 顶层 结构 及 启动 过 程 


7.1.1 Tomcat 的 顶层 结构 


Tomcat 中 最 顶层 的 容器 叫 Server， 代 表 整 个 服务 器 ，Server 中 包含 至 少 一 个 Service， 用 于 具体 提供 服务 。Service 主 要 包含 两 部 分 : Connector 和 Container。Connector 用 于 处 理 连 接 相关 的 事情 ， 
并 提供 Socket 与 request、response 的 转换 ，Container 用 于 封装 和 管理 Servlet， 以 及 具体 处 理 request 请 求 。 一 个 Tomcat 中 只 有 一 个 Server， 一 个 Server 可 以 包含 多 个 Service， 一 个 Service 只 有 一 个 
Container， 但 可 以 有 多 个 Connectors (因为 一 个 服务 可 以 有 多 个 连接 ， 如 同时 提供 http 和 https 连 接 ， 也 可 以 提供 相同 协议 不 同 端口 的 连接 ) ， 结 构图 如 图 7-1 所 示 。 


负责 网 络 连 接 、request/ 
response 的 创 建 等 


具体 处 理 Servlet 


| 2 
Container 
Cornnector 


图 7-1 Tomcat 整 体 结构 图 


Tomcat 里 的 Server 由 org.apache.catalina.startup.Catalina 来 管理 ，Catalina 是 整个 Tomcat 的 管理 类 ， 它 里 面 的 三 个 方法 load、start、stop 分 别 用 来 管理 整个 服务 器 的 生命 周期 ，load 方 法 用 于 根据 
conf/server.xml 文 件 创建 server 并 调用 Server 的 init 方 法 进行 初始 化 ，start 方 法 用 于 启动 服务 器 ，stop 方 法 用 于 停止 服务 器 ，start 和 stop 方 法 在 内 部 分 别 调用 了 Server 的 start 和 stop 方 法 ，load 方 法 内 部 调 
了 Server 的 init 方 法 ， 这 三 个 方法 都 会 按 容器 的 结构 逐 层 调 用 相应 的 方法 ， 比 如 ，Server 的 start 方 法 中 会 调用 所 有 的 Service 中 的 start 方 法 ，Service 中 的 start 方 法 又 会 调用 所 有 包含 的 Connectors 和 
Container 的 start 方 法 ， 这 样 整个 服务 器 就 启动 了 ，init 和 stop 方 法 也 一 样 ， 这 就 是 Tomcat 生 命 周期 的 管理 方式 ， 更 加 具体 的 内 容 见 7.2 节 。Catalina 还 有 个 方法 也 很 重要 ， 那 就 是 await 方 法 ，Catalina 中 的 
await 方 法 直接 调用 了 Server 的 await 方 法 ， 这 个 方法 的 作用 是 进入 一 个 循环 ， 让 主线 程 不 会 退出 。 


不 过 Tomcat 的 入 口 main 方 法 并 不 在 Catalina 类 里 ， 而 是 在 org.apache.catalina.startup.Bootstrap 中 。Bootstrap 的 作用 类 似 一 个 CatalinaAdaptor， 具 体 处 理 过 程 还 是 使 用 Catalina 来 完成 的 ， 这 么 
做 的 好 处 是 可 以 把 启动 的 入 口 和 具体 的 管理 类 分 开 ， 从 而 可 以 很 方便 地 创建 出 多 种 启动 方式 ， 每 种 启动 方式 只 需要 写 一 个 相应 的 CatalinaAdaptor 就 可 以 了 。 


7.1.2 ”Bootstrap 的 启动 过 程 


Bootstrap 是 Tomcat 的 入 口 ， 正 常情 况 下 启动 Tomcat 就 是 调用 的 Bootstrap 的 main 方 法 ， 


代码 如 下 : 


// org.apache.catalina.startup.Bootstrap 
public static void main (String args[]) { 
// 先 新 建 一 个 Bootstrap 


if (daemon == null) { 
Bootstrap bootstrap = new Bootstrap(); 
tr 


{ 
// 初 始 化 了 ClassLoader， 并 用 ClassLoader 创 建 了 Catalina 实 例 ， 赋 给 catalinaDaemon 变 量 
bootstrap.init (); 
} catch (Throwable t) { 
handleThrowable (t); 
t.printstackTrace (); 
return; 
} 
daemon = bootstrap; 
} else { 

Thread.currentThread () .setContextClassLoader (daemon.catalinaLoader); 
} 
try { 

String command = "start"; 

if (args.length > 0) { 
command = args [args.length - 1]; 

} 

if (command.equals("startd")) { 
args[args.length ~- 1] = "start"; 
daemon. load (args); 
daemon. start (); 

} else if (command.equals("stopd")) { 


args[args.length - 1] = "stop"; 
daemon. stop (); 
} else if (command.equals("start")) { 


daemon. setAwait (true); 
daemon.1load (args); 
daemon.start (); 

else if (command.equals ("stop")) { 
daemon. stopServer (args) 7 


} else if (command.equals ("configtest")) { 
daemon.1load (args); 
if (null==daemon.getServer()) { 


System.exit (1); 
i 
System.exit (0); 
else { 


1og.warn ("Bootstrap: command \"" + command + "\" does not exist."); 


} 
} catch (Throwable t) { 
if (t instanceof InvocationTargetException && 
t.getCause() != null) { 
t = t.getCause(); 


} 

handleThrowable (t); 
七 .PrintStackTrace (); 
System.exit (1) 7 


可 以 看 到 这 里 的 main 非 常 简单 ， 只 有 两 部 分 内 容 : 首先 新 建 了 Bootstrap， 并 执行 init 方 法 初始 化 ; 然后 处 理 main 方 法 传 入 的 命令 ， 如 果 args 参 数 为 空 ， 默 认 执行 start。 


在 init 方 法 里 初始 化 了 ClassLoader， 并 用 ClassLoader 创 建 了 Catalina 实 例 ， 然 后 赋 给 catalinaDaemon 变 量 ， 后 面 对 命 令 的 操作 都 要 使 用 catalinaDaemon 来 具体 执行 。 


对 start 命 令 的 处 理 调用 了 三 个 方法 : setAwait (true) 、load (args) 和 start0。 这 三 个 方法 内 部 都 调用 了 Catalina 的 相应 方法 进行 具体 执行 ， 只 不 过 是 用 反射 来 调用 的 。start 方 法 (另外 两 个 方法 会 
处 理 一 些 参数 ， 调 用 方法 类 似 ) 的 代码 如 下 : 


// org.apache.catalina.startup.Bootstrap 
Public void start() 
throws Exception { 
if( catalinaDaemon==null ) init(); 
Method method = catalinaDaemon.getClass () . a (Class [] Jnull}y; 
method.invoke (catalinaDaemon, (Object [])null) 


这 里 首先 判断 catalinaDaemon 有 没有 初始 化 ， 如 果 没 有 则 调用 init 方 法 对 其 进行 初始 化 ， 然 后 使 用 Method 进 行 反射 调用 Catalina 的 start 方 法 。Method 是 java.lang.reflect 包 里 的 类 ， 代 表 一 个 具体 的 
方法 ， 可 以 使 用 其 中 的 invoke 方 法 来 执行 所 代表 的 方法 ，invoke 方 法 有 两 个 参数 ， 第 一 参数 是 Method 方 法 所 在 的 实体 ， 第 二 个 参数 是 可 变 参数 用 于 Method 方 法 执行 时 所 需要 的 参数 ， 所 以 上 面 的 调用 相 
当 于 ( (Catalina) catalinaDaemon) .start0。setAwait 和 load 也 用 类 似 的 方法 调用 了 Catalina 中 的 setAwait 和 load 方 法 。 


7.1.3 ”Catalina 的 启动 过 程 


从 前 面 的 内 容 可 以 知道 ，Catalina 的 启动 主要 是 调用 setAwait、load 和 start 方 法 来 完成 的 。setAwait 方 法 用 于 设置 Server 启 动 完成 后 是 否 进入 等 待 状 态 的 标志 ， 如 果 为 true 则 进入 ， 否 则 不 进入 ; load 
方法 用 于 加 载 配置 文件 ， 创 建 并 初始 化 Server; start 方 法 用 于 启动 服务 器 。 下 面 分 别 来 看 一 下 这 三 个 方法 。 


首先 来 看 setAwait 方 法 ， 代 码 如 下 : 


// org.apache.catalina.startup.Catalina 
Public void setAwait (boolean b) { 
await = b; 


} 


这 个 方法 非常 简单 ， 就 是 设置 await 属 性 的 值 ，await 属 性 会 在 start 方 法 中 的 服务 器 启动 完 之 后 使 用 它 来 判断 是 否 进入 等 待 状态 。 


Catalina 的 load 方 法 根据 conf/server.xml 创 建 了 Server 对 象 ， 并 赋值 给 server 属 性 (具体 解析 操作 是 通过 开源 项 目 Digester 完 成 的 ) ， 然 后 调用 了 server 的 init 方 法 ， 代 码 如 下 : 


// org.apache.catalina.startup.Catalina 
public void load() { 
long tl1 = System.nanoTime () 7 
// 省 略 创建 server 代 码 ， 创 建 过 程 使 用 Digester 完 成 
try { 
Y getServer () .init (); 
} catch (LifecycleException e) { 
if (Boolean.getBoolean("org.apache.catalina.startup.EXIT ON _INIT FAILURE")) { 
throw new java.lang.Error (e); 
} else { 
log.error ("Catalina.start", e); 
} 
} 
long t2 = System.nanoTime (); 
if(log. 人 { 
// 启 动 过 程 中 ， 全 可 以 看 到 
log.info(" Thitialization Processed in " + ((t2 - tl) / 1000000) + " ms"); 


Catalina 的 start 方 法 主要 调用 了 server 的 start 方 法 启动 服务 器 ， 并 根据 await 属 性 判断 是 否 让 程序 进入 了 等 待 状态 ， 代 码 如 下 : 


//org.apache.catalina.startup.Catalina 
public void start() { 
if (getServer() 一 null) { 
10ad(); 
} 
long tl1 = System.nanoTime () 7 
try { 
// 调用 Server 的 start 方 法 启动 服务 器 
getServer () .start (); 
} catch (LifecycleException e) { 
1og.fatal (sm.getString ("catalina.serverStartFail"), e); 
try { 
getServer () .destroy (); 
} catch (LifecycleException el) { 
log.debug ("destroy() failed for failed Server ", el); 
} 
return; 
} 
long t2 = System.nanoTime () 7 
if(1log.isInfoPnabledq()) { 
1og.info("Server startup in " + ((t2 - tl) / 1000000) + " ms"); 


7 此 处 省 略 了 注册 关闭 钩子 代码 
// 进入 等 待 状态 
if (await) { 

await (); 


这 里 首先 判断 Server 是 否 已 经 存在 了 ， 如 果 不 存 在 则 调用 load 方 法 来 初始 化 Server， 然 后 调用 Server 的 start 方 法 来 启动 服务 器 ， 最 后 注册 了 关闭 钩子 并 根据 await 属 性 判断 是 否 进入 等 待 状态 ， 之 前 我 们 
已 将 这 里 的 await 属 性 设置 为 true 了 ， 所 以 需要 进入 等 待 状态 。 进 入 等 待 状态 会 调用 await 和 stop 两 个 方法 ，await 方 法 直接 调用 了 Server 的 await 方 法 ，Server 的 await 方 法 内 部 会 执行 一 个 while 循 环 ， 这 样 
程序 就 停 到 了 await 方 法 ， 当 await 方 法 里 的 while 循 环 退出 时 ， 就 会 执行 stop 方 法 ， 从 而 关闭 服务 器 。 


7.1.4 ”Server 的 启动 过 程 


StandardServer 


Server 接 口中 提供 addService (Service service) 、removeService (Service service) 来 添加 和 删除 Service，Server 的 init 方 法 和 start 方 法 分 别 循环 调用 了 每 个 Service 的 init 方 法 和 start 方 法 来 启动 所 


有 Service。 


Server 的 默认 实现 是 org.apache.catalina.core.StandardServer，StandardServer 继 承 自 Lifecycle-MBeanBase，LifecycleMBeanBase 又 继承 
LifecycleBase 中 ，LifecycleBase 里 的 init 方 法 和 start 方 法 又 调 


自 LifecycleBase，init 和 start 方 法 就 定义 在 了 

initInternal 方 法 和 startlnternal 方 法 ， 这 两 个 方法 都 是 模板 方法 ， 由 子 类 具体 实现 ， 所 以 调用 StandardSserver 的 init 和 start 方 法 时 会 执行 
自己 的 initinternal 和 startlnterna| 方 法 ， 这 就 是 Tomcat 生 命 周期 的 管理 方式 ， 更 详细 的 过 程 见 7.2 节 。StandardServer 中 
start 和 init 方 法 ， 代 码 如 下 : 


的 initlnternal 和 startlnternal 方 法 分 别 循环 调用 了 每 一 个 service 的 


//org.apache.catalina.core.StandardServer 
protected void startInternal () throws LifecycleException { 
synchronized (servicesLock) { 
for (int i = 0; i < services.length; i++) { 
services[i] .start() 7 
} 
protected void initInternal () throws LifecycleException { 
for (int i = 0; i < services.length; i++) { 
services[i] .init()7 


k 


除了 startlnternal 和 initlnternal 方 法 ，StandardSserver 中 还 实现 了 await 方 法 ，Catalina 中 就 是 调 


//org.apache.catalina.core.StandardServer 
public void await() { 
// 如 果 端 口 为 -2 则 不 进入 循环 ， 直 接 返 回 
if( port == -2 ) { 
return; 
} 
// 如 果 端 口 为 -1 则 进入 循环 ， 而 且 无 法 通过 网 络 退 出 
if( port==-1 ) { 
try { 
awaitThread = Thread.currentThread () 7 
while(!stopAwait) { 
try { 
Thread.sleep( 10000 ); 
} catch( InterruptedException ex ) { 
// continue and check the flag 
E 


} 
} finally { 
awaitThread = null; 


} 


return; 


} 

// 如 果 端 口 不 是 -1 和 -2 (应 该 大 于 0) ， 则 会 新 建 一 个 监听 关闭 命令 的 ServerSocket 
awaitSocket = new ServerSocket (port, 1,InetAddress.getByName (adqress) ) 
while (!stopAwait) { 


ServerSocket serverSocket = awaitSocket; 
if (serverSocket == null) { 
break; 


} 
Socket socket = null; 
StringBuilder command = new StringBuilder () 7 
InputStream stream; 
socket = serverSocket.accept (); 
socket .setSoTimeout (10 * 1000); 
stream = socket.getInputStream(); 
// 检查 在 指定 端口 接收 到 的 命令 是 否 和 shutdown 命 令 相 匹配 
boolean match = command.toString () .equals (shutdown); 
// 如 果 匹 配 则 跳出 循环 
if (match) { 
break; 


} 


它 让 服务 器 进入 等 待 状态 的 ， 其 核心 代码 如 下 : 


await 方 法 比较 长 ， 为 了 便于 大 家 理解 ， 这 里 省 略 了 一 些 处 理 异常 、 关 闭 Socket 以 及 对 接收 到 数据 处 理 的 代码 。 处 理 的 大 概 逻 辑 是 首先 判断 端口 号 port， 然 后 根 : 


port 为 -2， 则 会 直接 退出 ， 不 进入 循环 。 


居 port 的 值 分 为 三 种 处 理 方法 : 


“ port 为 -1 ， 则 会 进入 一 个 while (IstopAwait) 的 循环 ， 并 且 在 内 部 没有 break 跳 出 的 语句 ，stopAwait 标 志 只 有 调用 了 stop 方 法 才 会 设置 为 tue， 所 以 port 为 -1 时 只 有 在 外 部 调用 stop 方 法 才 会 退出 循环 。 


“ port 为 其 他 值 ， 则 也 会 进入 一 个 while (IstopAwait) 的 循环 ， 不 过 同时 会 在 port 所 在 端口 启动 一 个 ServerSocket 来 监听 关闭 命令 ， 


这 里 的 端口 port 和 关闭 命令 shutdown 是 在 conf/serverxml 文 件 中 配置 Server 时 设置 的 ， 默 认 设置 如 下 : 


如 果 接 收 到 了 则 会 使 用 bre 冰 跳出 循环 。 


果 接 收 到 的 数 拉 


<!-- server.xml --> 
<Server port="8005" shutdown="SHUTDOWN"> 


这 时 会 在 8005 端 口 监听 "SHUTDOWN "命令 ， 如 果 接收 到 了 就 会 关闭 Tomcat。 如 果 不 想 使 用 网 络 命令 来 关闭 服务 器 可 以 将 端口 


7.1.5 ”Service 的 启动 过 程 


Service 的 默认 实现 是 org.apache.catalina.core.StandardService，StandardService 也 继承 自 LifecycleMBeanBase 类 ， 所 以 init 和 start 方 法 最 终 也 会 调 
下 这 两 个 方法 的 核心 内 容 (省 略 了 异常 处 理 和 日 志 打印 代码 ) 。 


居中 有 ASCII 码 小 于 32 的 (ASClIl 中 32 以 下 的 为 控制 符 ) 则 会 从 小 于 32 的 那个 字符 截断 并 丢弃 后 画 


的 数据 ， 为 了 便 3 


设置 为 -1。 另 外 await 方 法 中 从 端口 接收 到 数据 后 还 会 进行 简单 处 理 ， 如 


大 家 理解 这 部 分 代码 我 们 在 上 


回 


省 略 掉 了 。 


initlnternal 和 startlnternal 方 法 ， 我 们 来 看 一 


// org.apache.catalina.core.StandardService 
protected void initInternal () throws LifecycleException { 
super.initInternal (); 
if (container != null) { 
container.init (); 
} 
for (Executor executor : findExecutors()) { 
if (executor instanceof JmxEnabled) { 
( (JmxEnabled) executor) .setDomain (getDomain ()); 
} 
executor.init (); 
mapperListener.init (); 
synchronized (connectorsLock) { 
for (Connector connector : connectors) { 
connector.init (); 
} 
} 
} 


protected void startInternal () throws LifecycleException { 


setState (LifecycleState.STARTING) 7 


3 


} 
Sync 


} 


container != null) { 


synchronized (container) { 


container.start (); 


} 


hronized (executors) { 


for (Executor executor: executors) { 


executor. start (); 


} 


mapperListener. start (); 


Sync 


hronized (connectorsLock) 
for (Connector connector: 


, 


connectors) { 


if (connector.getState() != LifecycleState.FAILED) { 
connector.start (); 


} 


可 以 看 到 


过 ，mapper 


Listener 是 Mapper 的 监听 器 ， 


就 可 以 看 到 其 使 用 方法 ， 如 下 所 示 : 


，StandardSservice 中 的 initlnternal 和 startlnternal 方 法 主要 调 上 


container、executors、mapperListener、connectors 的 init 和 start 方 法 。 这 里 的 container 和 connectors 前 面 已 经 介绍 


可 以 监听 container 容 器 的 变化 ，executors 是 用 在 connectors 中 管理 线程 的 线程 池 ， 在 serverx.xm 人 配置 文件 中 有 参考 用 法 ， 不 过 默认 是 注释 起 来 的 ， 打 开 注 释 


<Service 


name="Catalina"> 


<Executor name="tomcatThreadPool" namePrefix="catalina-exec-" 


<Connector executor="tomcatThreadPool" 


</Servic 


port="8080" protocol=" 


TR/ 1Y 


ConnectionTimeout="20000" 
redirectPort="8443"™ />……… 


e> 


这 样 Connector 就 配置 了 一 个 叫 tomcatThreadPool 的 线程 池 ， 最 多 可 以 同时 启动 150 个 线程 ， 最 少 要 有 4 个 可 用 线程 。 


现在 整个 Tomcat 服 务 器 就 启动 了 ， 整 个 启动 流程 如 图 7-2 所 示 。 
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1.3, 


7.2 Tomcat 的 生命 周期 管理 


7.2.1 Lifecycle 接 口 


图 7-2” Tomcat 顶层 组 件 启动 时 序 图 


Tomcat 通 过 org.apache.catalina.Lifecycle 接 口 统一 管理 生命 周期 ， 所 有 有 生命 周期 的 组 件 都 要 实现 Lifecycle 接 口 。Lifecycle 接 


“ 定义 了 13 个 String 类 型 常量 ， 用 于 LifecycleEvent 事 件 的 type 属 性 中 ， 作 用 是 区 分 组 件 发 出 的 LifecycleEvent 事 件 时 的 状态 (如 初始 
种 类 型 的 事件 (LifecycleEvent) 然后 用 其 中 的 一 个 属性 来 区 分 状态 而 不 用 定义 多 种 事件 ， 我 们 要 学 习 和 借鉴 这 种 方式 。 
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一 共 做 了 4 件 


比 前、 启动 前 、 启 动 中 等 ) 。 这 种 设计 方式 可 以 让 多 种 状态 都 发 送 同一 


' 定义 了 三 个 管理 监听 器 的 方法 addLifecycleListener、findLifecycleListeners 和 remove-LifecycleListener， 分 别 用 来 添加 、 查 找 和 删除 LifecycleListener 类 型 的 监听 器 。 


“ 定义 了 4 个 生命 周期 的 方法 : init、start、stop 和 destroy， 用 于 执行 生命 周期 的 各 个 阶段 的 操作 。 


“ 定义 了 获取 当前 状态 的 两 个 方法 getState 和 getStateName， 用 来 获取 当前 的 状态 ，getState 的 返回 值 LifecycleState 是 枚 举 类 型 ， 里 边 列举 了 生命 周期 的 各 个 节点 ，getStateName 方 法 返回 String 类 型 的 状态 的 


名 字 ， 主 要 用 于 JMX 中 。 


Lifecycle 接 口 定义 如 下 : 


// org.apache.catalina.Lifecycle 

public interface Lifecycle { 
// 13 种 LifecycleEvent 事 件 的 类 型 
public static final String BEFORE INIT EVENT = "before init"; 
public static final String AFTER INIT FVENT = "after init"; 
public static final String START EVENT = "start"; 
public static final String BEFORE START EVENT = "before start"; 
public static final String AFTER START EVENT = "after start"; 
public static final String STOP FVENT = "stop" 加 
public static final String BEFORE STOP EVENT = "before stop"; 
public static final String AFTER STOP EVENT = "after stop"; 
public static final String AFTER DESTROY EVENT = "after destroy"; 
public static final String BEFORE DESTROY FEVENT = "before destroy"; 
public static final String PERIODIC EVENT = "periodic"; 
public static final String CONFIGURE START FVENT = "configure start"; 
public static final String CONFIGURE STOP EVENT = "configure stop"; 
// 3 个 管理 监听 器 的 方法 
public void adgdLifecycleListener (LifecycleListener listener); 
public LifecycleListener[] findLifecycleListeners(); 
public void removeLifecycleListener (LifecycleListener listener); 
// 4 个 生命 周期 方法 
public void init() throws LifecycleException; 
Public void start() throws LifecycleException; 
public void stop () throws LifecycleException; 
public void destroy() throws LifecycleException; 
// 2 个 获取 当前 状态 的 方法 
public LifecycleState getState(); 
public String getStateName () 7 


7.2.2 LifecycleBase 


Lifecycle 的 默认 实现 是 org.apache.catalina.util.LifecycleBase， 所 有 实现 了 生命 周期 的 组 件 都 直接 或 间接 地 继承 自 LifecycleBase，LifecycleBase 为 Lifecycle 里 的 接口 方法 提供 了 默认 实现 : 监听 器 管 
理 是 专门 使 用 了 一 个 LifecycleSupport 类 来 完成 的 ，LifecycleSupport 中 定义 了 一 个 LifecycleListener 数 组 类 型 的 属性 来 保存 所 有 的 监听 器 ， 然 后 并 定义 了 添加 、 删 除 、 查 找 和 执行 监听 器 的 方法 ;生命 周期 
方法 中 设置 了 相应 的 状态 并 调用 了 相应 的 模板 方法 ，init、start、stop 和 destroy 所 对 应 的 模板 方法 分 别 是 initlnternal、startlnternal、stoplnternal 和 destroylnternal 方 法 ， 这 四 个 方法 由 子 类 具体 实现 ， 
所 以 对 于 子 类 来 说 ， 执 行 生命 周期 处 理 的 方法 就 是 initlinternal、startlnternal、stoplnternal 和 destroylnternal; 组 件 当前 的 状态 在 生命 周期 的 四 个 方法 中 已 经 设置 好 了 ， 所 以 这 时 直接 返回 去 就 可 以 了 。 
下 面 分 别 来 看 一 下 实现 的 过 程 。 


回 


三 个 管理 监听 器 的 方法 


管理 监听 器 的 添加 、 查 找 和 删除 的 方法 是 使 用 LifecycleSupport 来 管理 的 ， 代 码 如 下 : 


// org.apache.catalina.util.LifecycleBase 

private final LifecycleSupport lifecycle = new LifecycleSupport (this); 

QOverride 

public void addLifecycleListener (LifecycleListener listener) { 
lifecycle.addLifecycleListener (listener); 


} 

public LifecycleListener[] findLifecycleListeners() { 
return lifecycle.findLifecycleListeners(); 

} 

Override 

Public void removeLifecycleListener (LifecycleListener listener) { 
lifecycle.removeLifecycleListener (listener); 


} 


LifecycleBase 中 的 addLifecycleListener、findLifecycleListeners 和 removeLifecycleListener 方 法 分 别 调用 了 LifecycleSupport 中 的 同名 方法 ，LifecycleSupport 监 听 器 是 通过 一 个 数组 属性 listeners 来 
保存 的 ， 代 码 如 下 : 


//org.apache.catalina.util.LifecycleSupport 
// 用 于 保存 监听 器 
private LifecycleListener listeners[] = new LifecycleListener[0]; 
// 当 监听 器 发 生变 化 时 进行 同步 的 同步 锁 
Private final Object listenersLock = new Object () 7 
// 添加 一 个 监听 器 
public void addLifecycleListener (LifecycleListener listener) { 
synchronized (listenersLock) { 
LifecycleListener results[] = new LifecycleListener[listeners.length + 1]; 
for (int i = 0; i < listeners.length; i++) 
results[i] = listeners[i]; 
results[listeners.length] = listener; 
listeners = results; 


} 


} 

// 获取 所 有 监听 器 

public LifecycleListener[] findLifecycleListeners () { 
return listeners; 


E 

// 删除 一 个 监听 器 

public void removeLifecycleListener (LifecycleListener listener) { 
synchronized (listenersLock) { 


int n= -1; 
for (int i = 0; i < listeners.length; i++) { 
if (listeners[i] == listener) { 
n= 1} 
break; 
} 
} 
if (n < 0) 
return; 


LifecycleListener results[] = 
new LifecycleListener[listeners.length - 1]; 
int 了 = 0; 
for (int i = 0; i < listeners.length; i++) { 
if (i != n) 
results[j++] = listeners[i]; 
} 


listeners = results; 


这 三 个 方法 的 实现 非常 简单 ， 就 是 对 listeners 属 性 进行 操作 ， 只 是 因为 listeners 是 数组 类 型 ， 所 以 具体 操作 起 来 有 点 复杂 ， 添 加 的 时 候 先 新 建 一 个 比 当前 数组 大 1 的 数组 ， 然 后 将 原来 的 数据 按 顺 序 保存 
进去 ， 并 将 新 的 添加 进去 ， 最 后 将 新 建 的 数组 赋 给 listeners 属 性 ， 删 除 的 时 候 要 先 找到 要 删除 的 监听 器 在 数组 中 的 序号 ， 然 后 也 是 新 建 一 个 比 当前 数组 小 1 的 数组 ， 接 着 将 除了 要 删除 的 监听 器 所 在 序号 的 元 
素 按 顺序 添加 进去 ， 最 后 再 赋值 给 listeners 属 性 。 另 外 LifecycleSupport 中 还 定义 了 处 理 LifecycleEvent 事 件 的 fireLifecycleEvent 方 法 ， 代 码 如 下 : 


//org.apache.catalina.util.LifecycleSupport 
public void fireLifecycleEvent (String type, Object data) { 


LifecycleEvent event = new LifecycleEvent (lifecycle, type, data); 
LifecycleListener interested[] = listeners; 
for (int i = 0; i < interested.length; i++) 

interested[i] .lifecycleEvent (event); 


这 里 按 事件 的 类 型 (组 件 的 状态 ) 创建 了 LifecycleEvent 事 件 ， 然 后 遍历 所 有 的 监听 器 进行 了 处 理 。 


四 个 生命 周期 方法 


四 个 生命 周期 方法 的 实现 中 首先 判断 当前 的 状态 和 要 处 理 的 方法 是 否 匹配 ， 如 果 不 匹 配 就 会 执行 相应 方法 使 其 匹配 (如 在 init 之 前 调用 了 start， 这 时 会 先 执行 init 方 法 ) ， 或 者 不 处 理 甚 至 抛 出 异常 ， 如 
果 匹 配 或 者 处 理 后 匹配 了 ， 则 会 调用 相应 的 模板 方法 并 设置 相应 的 状态 。LifecycleBase 中 的 状态 是 通过 LifecycleSstate 类 型 的 state 属 性 来 保存 的 ， 最 开始 初始 化 值 为 Lifecyclestate.NEW。 我 们 来 看 一 下 init 
方法 : 


// org.apache.catalina.util.LifecycleBase 
public final synchronized void init() throws LifecycleException { 
// 开 始 的 状态 必须 是 LifecycleState.NEW， 否 则 就 会 抛 出 异常 
if (!state.equals (LifecycleState.NEW)) { 
invalidTransition (Lifecycle.BEFORE INIT EVENT); 


} 

// 初 始 化 前 将 状态 设置 为 LifecycleState.INITIALIZING 
SetStateInternal (LifecycleState.INITIALIZING, null, false); 
try { 

// 通过 模板 方法 具体 执行 初始 化 
initInternal (); 
} catch (Throwable t) { 
ExceptionUtils.handleThrowable (t); 
SetStateInternal (LifecycleState.FAILED, null, false); 
throw new LifecycleException( 
sm.getString ("lifecycleBase.initFail",toString()), t); 


} 
// 初 始 化 后 将 状态 设置 为 LifecycleState.INITIALIZED 
SetStateInternal (LifecycleState.INITIALIZED, null, false); 


因为 init 方 法 是 最 开始 ， 所 以 状态 必须 是 LifecycleState.NEW， 如 果 不 是 就 抛 出 异常 。 如 果 开 始 的 状态 是 LifecycleState.NEW， 在 具体 初始 化 之 前 会 将 状态 设置 为 LifecycleState.INITIALIZING， 然 后 调 
模板 方法 initInternal 让 子 类 具体 执行 初始 化 ， 初 始 化 完成 后 将 状态 设置 为 LifecycleState.INITIALIZED。 


init 方 法 中 如 果 状 态 不 是 LifecycleState.NEW 会 调用 invalidTransition 方 法 抛 出 异常 ，invalidTransition 方 法 专门 用 于 处 理 不 符合 要 求 的 状态 ， 在 另外 三 个 方法 中 如 果 状 态 也 不 合适 而 且 不 能 进行 别 的 处 
有 @， 也 会 调用 invalidTransition 方 法 ， 其 代码 如 下 : 


// org.apache.catalina.util.LifecycleBase 
private void invalidTransition (String type) throws LifecycleException { 
String msg = sm.getString ("lifecycleBase.invalidTransition", type, 
toSstring(), state); 
throw new LifecycleException (msg); 


其 内 部 就 是 抛 出 了 一 个 LifecycleException 类 型 的 异常 。 


start 方 法 要 稍微 复杂 一 点 ， 我 们 来 看 一 下 : 


// org.apache.catalina.util.LifecycleBase 
public final synchronized void start() throws LifecycleException { 
// 通过 状态 检查 是 否 已 经 启动 ， 如 果 已 经 启动 则 打印 日 志 并 直接 返回 
if (LifecycleState.STARTING PREP.equals (state) || 
LifecycleState.STARTING.equals (state) || 
LifecycleState.STARTED.equals (state)) { 
if (log.isDebugEnabled()) { 
Exception e = new LifecycleException(); 
log.debug (sm.getString ("lifecycleBase.alreadyStarted", toString()), e); 
} else if (1og.isInfoPnabled()) { 
log.info(sm.getString ("lifecycleBase.alreadyStarted", tostring())); 
} 


return; 


} 
// 如 果 没 有 初始 化 先进 行 初始 化 ， 如 果 启 动 失败 则 关闭 ， 如 果 状 态 无 法 处 理 则 抛 出 异常 
if (state.equals (LifecycleState.NEW) ) { 
init()7 
} else if (state.equals (LifecycleState.FAILED) ){ 
stop(); 
} else if (!state.equals (LifecycleState.INITIALIZED) && 
!state.equals (LifecycleState.STOPPED)) { 
invalidTransition (Lifecycle.BEFORE START EVENT); 


} 
// 启 动 前 将 状态 设置 为 LifecycleState.STARTING PREP 
setStateInternal (LifecycleState.STARTING PREP, null, false); 


try { 
// 通过 调用 模板 方法 具体 启动 组 件 
startIinternal () 7 
} catch (Throwable 七 ) { 
ExceptionUtils .handleThrowable (t); 
// 启 动 失败 后 会 将 状态 设置 为 LifecycleState.FAILED 
SetStateInternal (LifecycleState.FAILED, null, false); 
throw new LifecycleException( 
sm.getString ("lifecycleBase.startrFail", tostring()), t); 


E 
// 如 果 启 动 失败 则 调用 stop 方 法 停止 
if (state.equals (LifecycleState.FAILED) || 
state.equals (LifecycleState.MUST STOP)) { 
stop(); 
} else { 
// 如 果 启 动 后 状态 不 是 LifecycleState .STARTING 则 抛 出 异常 
if (!state.equals (LifecycleState.STRARTING) ) { 
invalidTransition (Lifecycle.AFTER START EVENT) ; 


} 
// 成 功 启动 后 将 状态 设置 为 Lifecyclestate.STARTED 
SetStateInternal (LifecycleState.STARTED, null, false); 
} 


start 方 法 在 启动 前 先 判断 是 不 是 已 经 启动 了 ， 如 果 已 经 启动 了 则 直接 返回 ， 如 果 没 有 初始 化 会 先 执 行 初始 化 ， 如 果 是 失败 在 状态 就 会 调用 stop 方 法 进行 关闭 ， 如 果 状 态 不 是 前 面 那些 也 不 是 刚 初始 化 完 
或 者 已 经 停止 了 则 会 抛 出 异常 。 如 果 状 态 是 刚 初始 化 完 或 者 已 经 停止 了 ， 则 会 先 将 状态 设置 为 LifecycleState.STARTING_PREP， 然 后 执行 startlnternal 模 板 方法 调用 子 类 的 具体 启动 逻辑 进行 启动 ， 最 后 根 
据 是 否 启动 成 功 设置 相应 的 状态 。 其 实 主 要 就 是 各 种 状态 的 判断 设置 ，stop 和 destroy 方 法 的 实现 过 程 也 差不多 ， 就 不 具体 分 析 了 。 


设置 状态 的 setStatelnternal 方 法 中 除了 设置 状态 还 可 以 检查 设置 的 状态 合 不 合 逻 辑 ， 并 且 会 在 最 后 发 布 相应 的 事件 ， 其 代码 如 下 : 


// org.apache.catalina.util.LifecycleBase 
Private synchronized void setStateInternal (LifecycleState state, 
Object data, boolean check) throws LifecycleException { 
if (log.isDebugEnabled()) { 
log.debug (sm.getString ("lifecycleBase.setState", this, state)); 


if (check) { 
// 如 果 状 态 为 空 直 接 抛 出 异常 并 退出 ， 
if (state 一 null) { 
invalidTransition("nul1") 7 
return; 


} 
// 如 果 状 态 不 符合 逻辑 则 抛 出 异常 


正常 情况 下 状态 是 不 会 为 空 的 


if (! (state 一 LifecycleState.FAILED || 
(this.state 一 LifecycleState.STARTING PREP && 
state 一 LifecycleState.STARTING) || 


(this.state = 


LifecycleState.STOPPING PREP && 


state 一 LifecycleState.STOPPING) || 


(this.state = 


LifecycleState.FAILED && 


state 一 LifecycleState.STOPPING))) { 
invalidTransition (state.name () ) 7 


// 设置 为 新 状态 
this.state = state; 


// 发 布 事件 


String lifecycleEvent = state.getLifecycleEvent (); 


if (lifecycleEvent != null) { 


fireLifecycleEvent (lifecycleEvent, data); 


} 


setStatelnternal 方 法 中 通过 check 参 数 判 断 是 否 需要 检查 传 入 的 状态 ， 如 果 需 要 检查 则 会 检查 传 入 的 状态 是 否 为 空 和 是 否 符合 逻辑 ， 最 后 将 传 入 的 状态 设置 到 state 属 性 ， 并 调用 fireLifecycleEvent 方 
法 处 理事 件 ，fireLifecycleEvent 方 法 调用 了 LifecycleSupport 的 fireLifecycleEvent 方 法 来 具体 处 理 ， 代 码 如 下 : 


// org.apache.catalina.util.LifecycleBase 
Protected void fireLifecycleEvent (String type, Object data) { 
lifecycle.fireLifecycleEvent (type, data); 


} 


LifecycleSupport 的 fireLifecycleEvent 方 法 前 面 已 经 介绍 过 了 ， 它 里 面 首先 创建 了 LifecycleEvent 事 件 ， 然 后 遍历 所 有 的 监听 器 进行 处 理 。 


两 个 获取 当前 状态 的 方法 


在 生命 周期 的 相应 方法 中 已 经 将 状态 设置 到 了 state, 


属性 ， 所 以 获取 状态 的 两 个 方法 的 实现 就 非常 简单 了 ， 直 接 将 state 返 回 就 可 以 了 ， 代 码 如 下 : 


// org.apache.catalina.util.LifecycleBase 


QOverride 

public LifecycleState getState() { 
return state; 

} 

QOverride 

public String getStateName () { 
return getState () .tostring(); 

} 


7.3 Container 分 析 


7.3.1 ”ContainerBase 的 结构 


Container 是 Tomcat 中 容器 的 接口 ， 通 常 使 


的 Servlet 就 封装 在 其 子 接口 Wrapper 中 。Container 一 共有 4 个 子 接 | 


Engine、Host、Context、Wrapper 4 个 子 容器 都 符合 前 面 讲 过 的 Tomcat 生 命 周期 管理 模式 ， 结 构图 如 图 7-3 所 示 。 


@ Lifecycle 


@ Container © 


Engine、Host、Context、Wrapper 和 一 个 默认 实现 类 ContainerBase， 每 个 子 接 


口 都 是 一 个 容器 ， 这 4 个 子 容 器 都 有 一 个 对 应 的 StandardXXX 实 现 类 ， 并 且 这 些 实现 类 都 继承 ContainerBase 类 。 另 外 Container 还 继承 Lifecycle 接 口 ， 而 且 ContainerBase 间 接 继 承 LifecycleBase， 所 以 


©@ LifecycleBase 


LifecycleMBeanBase 


@ Context 


StandardContext 


7.3.2 ”Container 的 4 个 子 容器 


图 7-3 ”Container 结构 图 


@ StandardHost 


Container 的 子 容 器 Engine、Host、Context、Wrapper 是 逐 层 包含 的 关系 ， 其 中 Engine 是 最 顶层 ， 每 个 service 最 多 只 能 有 一 个 Engine，Engine 里 面 可 以 有 多 个 Host， 每 个 Host 下 可 以 有 多 个 
Context， 每 个 Context 下 可 以 有 多 个 Wrapper， 它 们 的 装配 关系 如 图 7-4 所 示 。 


每 个 Host 代 表 
一 个 虚拟 主机 


每 个 Context 


代表 一 个 应 用 


每 个 W rapper 封 
装着 一 个 Servlet 


Wrapper 


图 7-4 Container 容 器 装配 结构 图 


4 个 容器 的 作用 分 别 是 : 


Engine: 引 党， 用 来 管理 多 个 站 点 ， 一 个 Service 最 多 只 能 有 一 个 Engine。 
“ Host: 代表 一 个 站 点 ， 也 可 以 叫 虚拟 主机 ， 通 过 配置 Host 就 可 以 添加 站 点 。 
:Context: 代表 一 个 应 用 程序 ， 对 应 着 平时 开发 的 一 套 程序 ， 或 者 一 个 WEB-INF 目 录 以 及 下 面 的 web.xml 文 件 。 


* Wrapper: 每 个 Wrapper 封 装着 一 个 Servlet。 


Context 和 Host 的 区 别 是 Context 表 示 一 个 应 用 ， 比 如 ， 默 认 配置 下 webapps 下 的 每 个 目录 都 是 一 个 应 用 ， 其 中 ROOT 目录 中 存放 着 主 应 用 ， 其 他 目录 存放 着 别 的 子 应 用 ， 而 整个 webapps 是 一 个 站 
点 。 假 如 www.excelib.com 域 名 对 应 着 webapps 目 录 所 代表 的 站 点 ， 其 中 的 ROOT 目录 里 的 应 用 就 是 主 应 用 ， 访 问 时 直接 使 用 域名 就 可 以 ， 而 webapps/test 目 录 存 放 的 是 test 子 应 用 ， 访 问 时 需要 
www.excelib.comytest， 每 一 个 应 用 对 应 一 个 Context， 所 有 webapps 下 的 应 用 都 属于 www.excelib.com 站 点 ， 而 blog.excelib.com 则 是 另外 一 个 站 点 ， 属 于 另外 一 个 Host。 


7.3.3 ”4 种 容器 的 配置 方法 


Engine 和 Host 的 配置 都 在 conf/server.xml 文 件 中 ，server.xml 文 件 是 Tomcat 中 最 重要 的 配置 文件 ，Tomcat 的 大 部 分 功能 都 可 以 在 这 个 文件 中 配置 ， 比 如 下 面 是 简化 了 的 默认 配置 : 


<?xml version='1.0' encoding='utf-8'?> 
<Server port="8005" shutdown="SHUTDOWN"> 
<Service name="Catalina"> 
<Connector port="8080" protocol="HTTP/1.1" 
connectionTimeout="20000™ 
redirectPort="8443" /> 
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /> 
<Engine name="Catalina" defaultHost="localhost"> 
<Host name="localhost" appBase="webapps" 
UnpackWARs="true" autoDeploy="true"> 
</Host> 
</Engine> 
</Service> 
</Server> 


这 里 首先 定义 了 一 个 Server， 在 8005 端 口 监听 关闭 命令 “SHUTDOWN”; Server 里 定义 了 一 个 名 为 Catalina 的 Service; Service 里 定义 了 两 个 Connector， 一 个 是 HTTP 协 议 ， 一 个 是 AJP 协 议 ，AJP 主 
于 集成 (如 与 Apache 集 成 ) ; Service 里 还 定义 了 一 个 名 为 Catalina 的 Engine; Engine 里 定义 了 一 个 名 为 localhost 的 Host。 


Engine 和 Host 直 接 用 Engine、Host 标 签 定义 到 相应 位 置 就 可 以 了 。Host 标 签 中 的 name 属 性 代表 域名 ， 所 以 上 面 定 义 的 站 点 可 以 通过 localhost 访 问 ，appBase 属 性 指定 站 点 的 位 置 ， 比 如 ， 上 面 定 义 
的 站 点 就 是 默认 的 webapps 目 录 ，unpackWARs 属 性 表示 是 否 自动 解压 war 文 件 ，autoDeploy 属 性 表示 是 否 自 动 部 署 ， 如 果 autoDeploy 为 true 那 么 Tomcat 在 运行 过 程 中 在 webapps 目 录 中 加 入 新 的 应 
将 会 自动 部 署 并 启动 。 另 外 Host 还 有 一 个 Alias 子 标签 ， 可 以 通过 这 个 标签 来 定义 别名 ， 如 果 有 多 个 域名 访问 同一 个 站 点 就 可 以 这 么 定义 ， 如 www.excelib.com 和 excelib.com 要 访问 同一 个 站 点 ， 可 以 做 
下 配置 : 


<Host name="www.excelib.com" appBase="/hosts/excelib.com" 
unpackWARs="true" autoDeploy="true"> 
<Alias> excelib.com</Alias> 
</Host> 


Engine 在 定义 的 时 候 有 个 defaultHost 属 性 ， 它 表示 接收 到 请 求 的 域名 如 果 在 所 有 的 Host 的 name 和 Alias 中 都 找 不 到 时 使 用 的 默认 Host， 比 如 ， 我 们 定义 了 www.excelib.com 和 excelib.com 的 Host， 
但 是 blog.excelib.com 也 解析 到 了 这 人 台 主 机 的 IP， 但 是 Tomcat 却 找 不 到 blog.excelib.com 对 应 的 Host， 这 时 就 会 使 用 Engine 中 配置 的 defaultHost 来 处 理 ， 另 外 如 果 使 用 的 是 IP 直 接 访问 也 会 用 到 
defaultHost， 如 果 将 Engine 的 defaultHost 属 性 删除 ， 然 后 启动 后 用 127.0.0.1 来 访问 本 机 的 Tomcat 就 不 可 能 了 。 


Context 有 三 种 配置 方法 : @ 通 过 文件 配置 ，@ 将 WAR 应 用 直接 放 到 Host 目 录 下 ，Tomcat 会 自动 查找 并 添加 到 Host 中 ; @ 将 应 用 的 文件 夹 放 到 Host 目 录 下 ，Tomcat 也 会 自动 查找 并 添加 到 Host 中 。 


Context 通 过 文件 配置 的 方式 一 共有 5 个 位 置 可 以 配置 : 
“ conf/server.xml 文 件 中 的 Context 标 签 。 
“ conf/[enginename]/[hostname]/ 目 录 下 以 应 用 命名 的 xml 文 件 。 
“应 用 自己 的 /META-INF/context.xml 文 件 。 
“conf/context.xml 文 件 。 


“ conf/[enginename]/[hostname]/context.xml.default 文 件 。 


其 中 前 三 个 位 置 用 于 配置 单独 的 应 用 ， 后 两 个 配置 的 Context 是 共享 的 ，conf/context.xml 文 件 中 配置 的 内 容 在 整个 Tomcat 中 共享 ， 第 5 种 配置 的 内 容 在 对 应 的 站 点 (Host) 中 共享 。 另外， 因为 
conf/serverxml 文 件 只 有 在 Tomcat 重 启 的 时 候 才 会 重新 加 载 ， 所 以 第 一 种 配置 方法 不 推荐 使 用 。 


Wrapper 的 配置 就 是 我 们 在 web.xml 中 配置 的 Servlet， 一 个 Servlet 对 应 一 个 Wrapper。 另 外 也 可 以 在 conf/web.xml 文 件 中 配置 全 局 的 Wrapper， 处 理 Jsp 的 JspServlet 就 配置 在 这 里 ， 所 以 不 需要 自 
配置 Jsp 就 可 以 处 理 Jsp 请 求 了 。 


0 


4 个 Container 容 器 配置 的 方法 就 介绍 完了 。 需 要 注意 的 是 ， 同 一 个 Service 下 的 所 有 站 点 由 于 是 共享 Connector， 所 以 监听 的 端口 都 一 样 。 如 果 想 要 添加 监听 不 同 端口 的 站 点 ， 可 以 通过 不 同 的 Service 
来 配置 ，Service 也 是 在 conf/server.xml 文 件 中 配置 的 。 


7.3.4 Container 的 启动 


Container 的 启动 是 通过 init 和 start 方 法 来 完成 的 ， 在 前 面 分 析 过 这 两 个 方法 会 在 Tomcat 启 动 时 被 Service 调 用 。Container 也 是 按照 Tomcat 的 生命 周期 来 管理 的 ，init 和 start 方 法 也 会 调用 initlnternal 
和 startlnterna| 方 法 来 具体 处 理 ， 不 过 Container 和 前 面 讲 的 Tomcat 整 体 结构 启动 的 过 程 稍微 有 点 不 一 样 ， 主 要 有 三 点 区 别 : 


* Container 的 4 个 子 容器 有 一 个 共同 的 父 类 ContainerBase， 这 里 定义 了 Container 容 器 的 initInternal 和 startInternal 方 法 通用 处 理 内 容 ， 具 体 容 器 还 可 以 添加 自己 的 内 容 ; 
“除了 最 顶层 容器 的 init 是 被 Service 调 用 的 ， 子 容器 的 init 方 法 并 不 是 在 容器 中 逐 层 循环 调用 的 ， 而 是 在 执行 statt 方 法 的 时 候 通过 状态 判断 还 没有 初始 化 才 会 调用 ; 


“statt 方 法 除了 在 父 容器 的 startInternal 方 法 中 调用 ， 还 会 在 父 容器 的 添加 子 容器 的 addChild 方 法 中 调用 ， 这 主要 是 因为 Context 和 Wrapper 是 动态 添加 的 ， 我 们 在 站 点 目录 下 放 一 个 应 用 的 文件 夹 或 者 War 包 
就 可 以 添加 一 个 Context， 在 web.xml 文 件 中 配置 一 个 Servlet 就 可 以 添加 一 个 Wrapper， 所 以 Context 和 Wrapper 是 在 容器 启动 的 过 程 中 才 动 态 查 找 出 来 添加 到 相应 的 父 容 器 中 的 。 


先 分 析 一 下 Container 的 基础 实现 类 ContainerBase 中 的 initinternal 和 startinternal 方 法 ， 然 后 再 对 具体 容器 进行 分 析 。 


ContainerBase 


ContainerBase 的 initinternal 方 法 主要 初始 化 ThreadPoolExecutor 类 型 的 startStopExecutor 属 性 ， 


于 管理 启动 和 关闭 的 线程 ， 具 体 代码 如 下 : 


// org.apache.catalina.core.ContainerBase 
protected void initInternal () throws LifecycleException { 
BlockingQueue<Runnable> startStopQueue = new LinkedBlockingQueue<>(); 
StartStoPExecutor = new ThreadPoolExecutor( 
getStartStopThreadsInternal (), 
getStartStopThreadsInternal (), 10, TimeUnit.SECONDS, 
startStopQueue, 
new StartStopThreadFactory (getName () + "-startStop-—")); 
startSstopExecutor.allowCoreThreadTimeOut (true); 
SuUPer .initInternal (); 


ThreadPoolExecutor 继 承 自 Executor 用 于 管理 线程 ， 特 别 是 Runable 类 型 的 线程 ， 具 体 用 法 在 异步 处 理 的 相关 内 容 中 再 具体 讲解 。 另 外 需要 注意 的 是 ， 这 里 并 没有 设置 生命 周期 的 相应 状态 ， 所 以 如 果 
具体 容器 也 没有 设置 相应 生命 周期 状态 ， 那 么 即使 已 经 调用 init 方 法 进行 了 初始 化 ， 在 start 进 行 启动 前 也 会 再 次 调用 init 方 法 。 


ContainerBase 的 startlnternal 方 法 主要 做 了 5 件 事 : 


. 如 果 有 Cluster 和 Realm 则 调用 其 start 方 法 ; 

“ 调用 所 有 子 容器 的 start 方 法 启动 子 容器 ; 

“ 调用 管道 中 Value 的 start 方 法 来 启动 管道 (管道 的 内 容 7.4 节 会 详细 讲解 ) ; 
' 启动 完成 后 将 生命 周期 状态 设置 为 LifecycleState.STARTING 状 态 ; 

: 启用 后 台 线程 定时 处 理 一 些 事情 。 


代码 如 下 : 


protected synchronized void startInternal () throws LifecycleException { 

logger = null; 

getLogger (); 

// 如 果 有 Cluster 和 Realm 则 启动 

Cluster cluster = getClusterInternal (); 

if ((cluster != null) && (cluster instanceof Lifecycle)) 
((Lifecycle) cluster) .start(); 

Realm realm = getRealmInternal (); 

if ((realm != null) && (realm instanceof Lifecycle)) 
((Lifecycle) realm) .start(); 

// 获取 所 有 子 容器 

Container children[] = findChildren(); 

List<Future<Void>> results = new ArrayList<>(); 

for (int i = 0; i < children.length; I++) { 
// 这 里 通过 线程 调用 子 容器 的 start 方 法 ， 相 当 于 children[i] .start(); 
results.add (startStopExecutor.submit (new StartChild(children[i]))); 


} 
// 处 理子 容器 启动 线程 的 Future 
boolean fail = false; 
for (Future<Void> result : results) { 
try { 
result .get (); 
} catch (Exception e) { 
log.error (sm.getString ("containerBase.threadedstartFailed"), e); 
fail = true; 


} 


} 
if (fail) { 
throw new LifecycleException( 


sm.getString ("containerBase.threadedStartFailed")); 


} 
// 启动 管道 
if (pipeline instanceof Lifecycle) 

( (Lifecycle) pipeline) .start(); 
// 将 生命 周期 状态 设置 为 LifecycleState.STARTING 
SetState (LifecycleState.STARTING); 

// 启动 后 台 线 程 
threadStart (); 


这 里 首先 启动 了 Cluster 和 Realm， 启 动 方 法 是 直接 调用 它们 的 start 方 法 。Cluster 用 于 配置 集群 ， 在 server.xml 中 有 注释 的 参考 配置 ， 它 的 作用 就 是 同步 Session，Realm 是 Tomcat 的 安全 域 ， 可 以 用 来 
管理 资源 的 访问 权限 。 


子 容器 是 使 用 startStopExecutor 调 用 新 线程 来 启动 的 ， 这 样 可 以 用 多 个 线程 来 同时 启动 ， 效 率 更 高 ， 具 体 启动 过 程 是 通过 一 个 for 循 环 对 每 个 子 容 器 启动 了 一 个 线程 ， 并 将 返回 的 Future 保 存 到 一 个 List 
中 (更 多 线程 相关 内 容 会 在 异步 处 理 中 介绍 ) ， 然 后 遍历 每 个 Future 并 调用 其 get 方 法 。 遍 历 Future 主 要 有 两 个 作用 : @@ 其 get 方 法 是 阻塞 的 ， 只 有 线程 处 理 完 之 后 才 会 向 下 走 ， 这 就 保证 了 管道 Pipeline 启 
动 之 前 容器 已 经 启动 完成 了 ; @ 可 以 处 理 启动 过 程 中 遇 到 的 异常。 


回 


启动 子 容器 的 线程 类 型 StartChild 是 一 个 实现 了 Callable 的 内 部 类 ， 主 要 作用 就 是 调用 子 容器 的 start 方 法 ， 代 码 如 下 : 


// org.apache.catalina.core.ContainerBase 
private static class StartChild implements Callable<Void> { 
private Container child; 
public StartChild(Container child) { 
this.child = chilg; 
} 
QOverride 
public Void call() throws LifecycleException { 
child.start (); 
return null; 


因为 这 里 的 startinternal 方 法 是 定义 在 所 有 容器 的 父 类 ContainerBase 中 的 ， 所 以 所 有 容器 启动 的 过 程 中 都 会 调用 子 容器 的 start 方 法 来 启动 子 容器 。 


使 用 多 线程 在 实际 运行 过 程 中 可 以 提高 效率 ， 但 调试 起 来 会 比较 麻烦 ， 在 调试 分 析 Tomcat 代 码 的 过 程 中 可 以 直接 调用 子 容器 的 start 方 法 ， 也 就 是 将 如 下 代码 : 


for (int i = 0; i < children.length; i++) { 
results.add (startStopExecutor.submit (new StartChild(children[i]))); 
} 


改 为 


for (int i = 0; i < children.length; i++) { 
chilgdren[il] .start (); 
} 


这 样 调 试 就 简单 了 ，Future 相 关 的 代码 也 可 以 注释 起 来 。 


子 容器 启动 完成 后 接着 启动 容器 的 管道 ， 管 道 在 7.4 节 详细 讲解 ， 管 道 启动 也 是 直接 调用 start 方 法 来 完成 的 。 管 道 启动 完 之 后 设置 了 生命 周期 的 状态 ， 然 后 调用 threadStart 方 法 启动 了 后 台 线 程 。 


TT 


threadStart 方 法 启动 的 后 台 线 程 是 一 个 while 循 环 ， 内 部 会 定期 调用 backgroundProcess 方 法 做 一 些 事情 ， 间 隔 时 间 的 长 短 是 通过 ContainerBase 的 backgroundProcessorDelay 属 性 来 设置 的 ， 单 位 
是 秒 ， 如 果 小 于 0 就 不 启动 后 台 线程 了 ， 不 过 其 backgroundProcess 方 法 会 在 父 容器 的 后 台 线 程 中 调用 。backgroundProcess 方 法 是 Container 接 口中 的 一 个 方法 ， 一 共有 3 个 实现 ， 分 别 在 
ContainerBase、StandardContext 和 StandardWrapper 中 ，ContainerBase 中 提供 了 所 有 容器 共同 的 处 理 过 程 ，StandardContext 和 StandardWrapper 的 backgroundProcess 方 法 除了 处 理 自己 相关 的 
业务 ， 也 调用 ContainerBase 中 的 处 理 。ContainerBase 的 backgroundProcess 方 法 中 调用 了 Cluster、Realm 和 管道 的 backgroundProcess 方 法 ; StandardContext 的 background-Process 方 法 中 对 
Session 过 期 和 资源 变化 进行 了 处 理 ; StandardWrapper 的 backgroundProcess 方 法 会 对 Jsp 生 成 的 Servlet 定 期 进行 检查 。 


Engine 


Service 会 调用 最 顶层 容器 的 init 和 start 方 法 ， 如 果 使 用 了 Engine 就 会 调用 Engine 的 。Engine 的 默认 实现 类 StandardEngine 中 的 initlnternal 和 startlnternal 方 法 如 下 : 


// org.apache.catalina.core.StandardEngine 
protected void initInternal () throws LifecycleException { 
getRealm(); 
super.initIinternal (); 
} 
protected synchronized void startInternal () throws LifecycleException { 
if (log.isInforpnabled ()) 
log.info( "Starting Servlet Engine: " + ServerInfo.getServerInfo()); 
SUPer .StatrtInternal (); 


它们 分 别 调 用 了 ContainerBase 中 的 相应 方法 ，initlnternal 方 法 还 调用 了 getRealm 方 法 ， 其 作用 是 如 果 没有 配置 Realm， 则 使 用 一 个 默认 的 NullRealm， 代 码 如 下 : 


// org.apache.catalina.core.StandardEngine 
public Realm getRealm() { 
Realm configured = super.getRealm(); 
if (configured == null) { 
configured = new NullRealm(); 
this.setRealm (configured); 
} 


return configured; 


Host 


Host 的 默认 实现 类 StandardHost 没 有 重 写 initlnternal 方 法 ， 初 始 化 默认 调用 ContainerBase 的 initlnternal 方 法 ，startlnternal 方 法 代码 如 下 : 


//org.apache.catalina.core.StandardHost 
QOverride 
protected synchronized void startInternal () throws LifecycleException { 
// 如 果 管 道中 没有 ErrorReportValve 则 将 其 加 入 管道 
String errorValve = getErrorReportValveClass (); 
if ((errorValve != null) && (!errorValve.equals(""))) { 
try { 
boolean found = false; 
Valve[] valves = getPipeline () .getValves(); 
for (Valve valve : valves) { 
if (errorValve.equals (Valve.getClass () .getName ())) { 


found = true; 
break; 


} 


} 
if(!found) { 
Valve valve = 


(Valve) Class.forName (errorValve) .newInstance () 7 


getPipeline () .addValve (valve) 7 


} 

} catch (Throwable 七 ) { 
ExceptionUtils.handleThrowable (t); 
log.error (sm.getString( 


"standardHost .invalidErrorReportValveClass", 


errorValve), t); 
} 
} 


super.startIinternal (); 


这 里 的 代码 看 起 来 虽然 比较 多 ， 但 功能 却 非常 简单 ， 就 是 检查 Host 的 管道 中 有 没有 指定 的 Value， 如 果 没 有 则 添加 进去 。 检 查 的 方法 是 遍历 所 有 的 Value 然 后 通过 名 字 判 断 的 ， 检 查 的 Value 的 类 型 通过 
getErrorReportValveClass 方 法 获取 ， 它 返回 errorReportValveClass 属 性 ， 可 以 配置 ， 默 认 值 是 org.apache.catalina.valves.ErrorReportValve， 代 码 如 下 : 


//org.apache.catalina.core.StandardHost 


private String errorReportValveClass ="org.apache.catalina.valves.ErrorReportValve"; 


public String getErrorReportValveClass() { 
return (this.errorReportValveClass); 


} 


这 就 是 StandardHost 的 startlnternal 方 法 处 理 的 过 程 。Host 的 启动 除了 startlnternal 方 法 ， 还 有 HostConfig 中 相应 的 方法 ，HostConfig 继 承 自 LifecycleListener 的 监听 器 (Engine 也 有 对 应 的 


EngineConfig 监 听 器 ， 不 过 里 面 只 是 简单 地 做 了 日 志 记 录 ) ， 
不 是 目录 ， 最 后 调用 deployApps 方 法 部 署 应 用 ，deployApps 


// org.apache.catalina.startup.HostConfig 
protected void deployApps() { 

File appBase = host.getAppBaseFile(); 

File configBase = host.getConfigBaseFile(); 


在 接收 到 Lifecycle.START_EVENT 事 件 时 会 调用 start 方 法 来 启动 ，HostConfig 的 start 方 法 会 检查 配置 的 Host 站 点 配置 的 位 置 是 否 存 在 以 及 是 
方法 代码 如 下 : 


String[] filteredAppPaths = filterAppPaths (appBase.]list ()); 


// 部 署 XML 描述 文件 

deployDescriptors (configBase, configBase.list () 
// 部 署 NAR 文 件 

deployWARs (appBase, filteredAppPaths); 

// 部 署 文件 夹 

deployDirectories (appBase, filteredAppPaths); 


2 


一 共有 三 种 部 署 方式 : 通过 XML 描 述 文件 、 通 过 WAR 文 件 和 通过 文件 夹 部 署 。XML 文 件 指 的 是 conf/[enginename]/[hostname]/*.xml 文 件 ，WAR 文 件 和 文件 夹 是 Host 站 点 目录 下 的 WAR 文 件 和 文件 


夹 ， 这 里 会 自动 找 出 来 并 部 署 上 ， 所 以 我 们 如 果 要 添加 应 用 只 需要 直接 放 在 Host 站 点 的 目录 下 就 可 以 了 。 部 署 完成 后 ， 会 将 部 署 的 Context 通 过 StandardHost 的 addChild 方 法 添加 到 Host 里 面 。 


StandardHost 的 addChild 方 法 会 调用 父 类 ContainerBase 的 a 


Context 


ddChild 方 法 ， 其 中 会 调用 子 类 (这 里 指 Context) 的 start 方 法 来 启动 子 容器 。 


Context 的 默认 实现 类 StandardContext 在 startlnterna| 方 法 中 调用 了 在 web.xml 中 定义 的 Listener， 另 外 还 初始 化 了 其 中 的 Filter 和 load-on-startup 的 Servlet， 代 码 如 下 : 


// org.apache.catalina.core.StandardContext 
protected synchronized void startInternal () throws 


LifecycleException { 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/15447/OEBPS/Text/. .http://www.hzcourse.com/resource/readBook?path=/openresources/teach ek 


// 触发 listener 


if (ok) { 
if (!listenerStart()) { 
log.error( "Error listenerStart"); 
ok = false; 


} 


E 
// 初始 化 Filter 
if (ok) { 
if (1!1filterStart()) { 
log.error ("Error filterStart"); 
ok = false; 


i 


// 初始 化 Servlets 

if (ok) { 

if (!loadonstartup (findChildren())){ 
log.error ("Error loadonStartup"); 
ok = false; 


} 


} 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/15447/0EBPS/Text/. .http://www.hzcourse.com/resource/readBook?path=/openresources/teach ek 


istenerStart、filterStart 和 loadOnstartup 方 法 分 别 调 


配置 在 Listener 的 contextlnitialized 方 法 以 及 Filter 和 配置 了 load-on-startup 的 Servlet 的 init 方 法 。 


Context 和 Host 一 样 也 有 一 个 LifecycleListener 类 型 的 监听 器 ContextConfig， 其 中 configureStart 方 法 用 来 处 理 CONFIGURE_START_EVENT 事 件 ， 这 个 方法 里 面 调 用 webConfig 方 法 ,webConfig 
方法 中 解析 了 web.xml 文 件 ， 相 应 地 创建 了 Wrapper 并 使 用 addChild 添 加 到 了 Context 里 面 。 


Wrapper 


Wrapper 的 默认 实现 类 StandardWrapper 没 有 重 写 initlnternal 方 法 ， 初 始 化 时 会 默认 调用 ContainerBase 的 initlnternal 方 法 ，startlnternal| 方 法 代码 如 下 : 


// org.apache.catalina.core.StandardWrapper 


QOverride 
protected synchronized void startInternal () throws 
if (this.getObjectName() != null) { 


Notification notification = 
new Notification("j2ee.state.starting", 
broadcaster .sendNotification (notification); 
} 
super.startInternal (); 
setAvailable (0L); 
if (this.getObjectName() != null) { 
Notification notification = 
new Notification("j2ee.state.running", 
broadcaster .sendNotification (notification); 


这 里 主要 做 了 三 件 事情 : 


LifecycleException { 


this.getObjectName (), sequenceNumber++); 


this.getObjectName (), sequenceNumber++); 


“用 broadcaster 发 送 通 知 ， 主 要 用 于 JMX; 


“调用 了 父 类 ContainerBase 中 的 startInternal 方 法 ; 


* 调用 setAvailable 方 法 让 Servlet 有 效 。 


这 里 的 setAvailable 方 法 是 Wrapper 接 口中 的 方法 ， 其 作用 是 设置 Wrapper 所 包含 的 Servlet 有 效 的 起 始 时 间 ， 如 果 所 设置 的 时 间 为 将 来 的 时 间 ， 那 么 调用 所 对 应 的 Servlet 就 会 产生 错误 ， 直 到 过 了 所 设 
置 的 时 间 之 后 才 可 以 正常 调用 ， 它 的 类 型 是 long， 如 果 设 置 为 Long.MAX_VALUE 就 一 直 不 可 以 调用 了 。 


Wrapper 没 有 别 的 容器 那 种 XXXConfig 样 式 的 LifecycleListener 监 听 器 。 


7.4 Pipeline-Value 管 道 


7.3 节 讲 了 Container 自 身 的 创建 过 程 ，Container 处 理 请 求 是 使 用 Pipeline-Value 管 道 来 处 理 的 ， 本 节 就 详细 分 析 一 下 Pipeline-Value 管 道 。 首 先 介 绍 它 的 处 理 模式 ， 然 后 分 析 其 实现 方法 。 


7.4.1 ”Pipeline-Value 处 理 模 式 


Pipeline-Value 是 责任 链 模式 ， 责 任 链 模式 是 指 在 一 个 请 求 处 理 的 过 程 中 有 多 个 处 理 者 依次 对 请 求 进行 处 理 ， 每 个 处 理 者 负责 做 自己 相应 的 处 理 ， 处 理 完成 后 将 处 理 后 的 请 求 返回 ， 再 让 下 一 个 处 理 者 
继续 处 理 ， 就 好 像 驾 车 的 过 程 中 可 能 会 遇 到 很 多 次 交警 检查 ， 可 能 有 查 酒 驾 的 也 可 能 有 查 违章 的 ， 在 一 次 驾车 的 过 程 中 可 能 会 遇 到 多 次 检查 ， 这 就 是 责任 链 模式 ，Pipeline 就 相当 于 名 车 的 过 程 ，Value 相 当 
于 检查 的 交警 。 


不 过 Pipeline-Value 的 管道 模型 和 普通 的 责任 链 模式 稍微 有 点 不 同 ， 区 别 主 要 有 两 点 : @ 每 个 Pipeline 都 有 特定 的 Value， 而 且 是 在 管道 的 最 后 一 个 执行 ， 这 个 Value 叫 BaseValue，BaseValue 是 不 可 
删除 的 ，@ 在 上 层 容器 的 管道 的 BaseValue 中 会 调用 下 层 容器 的 管道 。 这 就 好 像 快递 的 配 货车 ， 配 货车 除了 在 路 途中 可 能 遇 到 交警 检查 外 ， 到 达 目 的 地 后 必然 还 会 被 中 转 站 检查 货物 ， 这 是 必 不 可 少 的 ， 如 
果 在 中 转 站 检查 后 没有 问题 就 会 把 货物 交 给 另外 的 货车 去 派送 ， 直 到 将 货物 送 到 客户 手中 ， 被 客户 检查 并 签收 。4 个 容器 的 BaseValue 分 别 是 StandardEngineValve、StandardHostValve、 
StandardContextValve 和 StandardWrapperValve， 整 个 处 理 的 流程 如 图 7-5 所 示 。 


在 Engine 的 管道 中 依次 执行 Engine 的 各 个 Value， 最 后 执行 StandardEngineValve， 用 于 调用 Host 的 管道 ， 然 后 执行 Host 的 Value， 这 样 依次 类 推 最 后 执行 Wrapper 管 道中 的 
StandardWrapperValve。 


在 Filter 中 用 到 的 FilterChain 其 实 就 是 这 种 模式 ，FilterChain 相 当 于 Pipeline， 每 个 Filter 都 相当 于 一 个 Value，Servlet 相 当 于 最 后 的 BaseValue。 


kngineValuel EngineValuel StandarEngineValve 


HostValuel HostValuel StandarHostValve 


ContextValuel ContextValuel standarContextValve 


WrapperPipeline 


WrapperValuel— > WrapperValuel StandarWrapperValve 


图 7-5 ”Pipeline 处 理 流程 


7.4.2 ”Pipeline-Value 的 实现 方法 
Pipeline 管 道 的 实现 分 为 生命 周期 管理 和 处 理 请 求 两 部 分 ， 下 面 分 别 介绍 。 


Pipeline 管 道生 命 周期 的 实现 方法 


Container 中 的 Pipeline 在 抽象 实现 类 ContainerBase 中 定义 ， 并 在 生命 周期 的 startlnternal、stoplnternal、destroylnternal 方 法 中 调用 管道 的 相应 生命 周期 方法 (因为 管道 不 需要 初始 化 所 以 
initInternal 方 法 中 并 没有 调用 ) ， 代 码 如 下 : 


//org.apache.catalina.core.ContainerBase 
protected final Pipeline pipeline = new StandardPipeline (this); 
protected synchronized void startInternal () throws LifecycleException { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/15447/OEBPS/Text/... 
// 调用 管道 的 启动 方法 
if (pipeline instanceof Lifecycle) 
((Lifecycle) pipeline) .start ();*… 


protected synchronized void stopInternal () throws LifecycleException { 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/15447/0EBPS/Text/... 


if (pipeline instanceof Lifecycle && 
((Lifecycle) pipeline) .getState () .isAvailable()) { 
( (Lifecycle) Pipeline) .stop () 7 


} 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/15447/OEBPS/Text/... 


protected void destroyInternal () throws LifecycleException {… 
if (pipeline instanceof Lifecycle) { 
( (Lifecycle) pipeline) .destroy () 


} 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/15447/OEBPS/Text/... 


Container 的 4 个 子 容器 都 继承 自 ContainerBase， 所 以 4 个 子 容器 在 执行 生命 周期 的 方法 时 都 会 调用 管道 相应 的 生命 周期 方法 。 


Pipeline 使 用 的 是 StandardPipeline 类 型 ， 它 里 面 的 Value 保 存在 first 属 性 中 ，Value 是 链 式 结构 ， 可 以 通过 getNext 方 法 依次 获取 每 个 Value，BaseValue 单 独 保存 在 basic 属 性 中 (basic 不 可 以 为 空 ， 
在 调用 addValve 方 法 添加 Value 时 basic 会 同时 保存 到 first 的 最 后 一 个 ， 如 果 没 调用 addValve 方 法 则 first 可 能 为 空 ) 。StandardPipeline 继 承 自 LifecycleBase， 所 以 实际 处 理 生命 周期 的 方法 是 


startlnternal、stoplnternal 和 destroylnternal， 代 码 如 下 : 


// org.apache.catalina.core.StandardPipeline 
QOverride 
protected synchronized void startInternal () throws LifecycleException { 
// 使 用 临时 变量 current 来 遍历 Value 链 里 的 所 有 Value， 如 果 first 为 空 则 使 用 basic 
Valve current = first; 
if (current == null) { 
Current = basic; 


} 
// 遍 历 所 有 Value 并 调用 start 方 法 
while (current != null) { 
if (current instanceof Lifecycle) 
( (Lifecycle) current) .statt () 7 
Current = current .getNext (); 
} 
// 设 置 LifecycleState.STARTING 状 态 
SetState (LifecycleState.STARTING); 
} 
QOverride 
protected synchronized void stopInternal () throws LifecycleException { 
setState (LifecycleState.STOPPING); 
Valve current = first; 
if (current == null) { 
Current = basic; 


while (current != null) { 
if (current instanceof Lifecycle) 
( (Lifecycle) current) .stop(); 
Current = current .getNext (); 
} 
} 
QOverride 
protected void destroyInternal () 
Valve[] valves = getValves(); 
for (Valve valve : valves) { 
removeValve (valve); 


{ 


} 


startinternal 方 法 和 stoplnternal 方 法 处 理 的 过 程 非常 相似 ， 都 是 使 用 临时 变量 current 来 遍历 Value 链 里 的 所 有 Value 
然后 设置 相应 的 生命 周期 状态 。destroylnternal 方 法 是 删除 所 有 Value，getValues 方 法 可 以 得 到 包括 basic 在 内 的 所 有 Val 


， 如 果 first 为 空 则 使 用 basic， 然 后 遍历 所 有 Value 并 调用 相应 的 start 和 stop 方 法 ， 
ue 的 集合 ， 代 码 如 下 : 


// org.apache.catalina.core.StandardPipeline 
QOverride 
public Valve[] getValves() { 
ArrayList<Valve> valveList = new ArrayList<>(); 
Valve current = first; 
if (current == null) { 
Current = basic; 


while (current != null) { 
valveList.add (current); 
Current = current .getNext (); 


return valveList.toArray (new Valve[0]); 


Pipeline 管 道 处 理 请 求 的 实现 方法 


Pipeline 调 用 所 包含 Value 的 invoke 方 法 来 处 理 请 求 ， 并 且 在 BaseValue 里 又 调用 了 子 容器 Pipeline 所 包含 Value 的 inv 
StandardWrapperValve。 


oke 方 法 ， 直 到 最 后 调用 了 Wrapper 的 Pipeline 所 包含 的 Base-Value 一 一 


Connector 在 接收 到 请 求 后 会 调用 最 顶层 容器 的 Pipeline 来 处 理 ， 顶 层 容 器 的 Pipeline 处 理 完 之 后 就 会 在 其 BaseValue 里 调用 下 一 层 容 器 的 Pipeline 进 行 处 理 ， 这 样 就 可 以 逐 层 调用 所 有 容器 的 Pipeline 


来 处 理 了 。Engine 的 BaseValue 是 StandardEngineValve， 它 的 invoke 代 码 如 下 : 


// org.apache.catalina.core.StandardEngineValve 
public final void invoke (Request request, Response response) 
throws IOException, ServletException { 
// Host 已 经 事先 设置 到 request 中 ， 其 他 各 层 容器 也 一 样 都 会 事先 设置 到 request 中 
Host host = request.getHost () 7 
if (host == null) { 
response.sendError 
(HttpServletResponse.sC BAD REQUEST, 
sm.getString ("standardEngine.noHost", 
request .getServerName () )); 
return; 
} 
if (request.isAsyncSupported()) { 
request .setAsyncSupported (host .getPipeline () .isAsyncSupported()); 


} 
// 将 请 求 传递 到 Host 的 管道 
host .getPipeline() .getFirst () .invoke (request, response); 


这 里 的 实现 非常 简单 ， 首 先 从 request 中 获取 到 Host， 然 后 调用 其 管道 的 第 一 个 Value 的 invoke 方 法 进行 处 理 。 Host 


的 BaseValue 也 同样 会 调用 Context 的 Pipeline，Context 的 BaseValue 会 调用 


Wrapper 的 Pipeline，Wrapper 的 Pipeline 最 后 会 在 其 BaseValue (Standard-WrapperValve) 中 创建 FiterChain 并 调 上 
Servlet， 其 doFilter 方 法 会 依次 调用 所 有 Filter 的 doFilter 方 法 和 Servlet 的 service 方 法 ， 这 样 请 求 就 得 到 处 理 了 。 


其 doFilter 方 法 来 处 理 请 求 ，FilterChain 包 含 着 我 们 配置 的 与 请 求 相 匹配 的 Filter 和 


Filter 和 Servlet 实 际 处 理 请 求 的 方法 在 Wrapper 的 管道 Pipeline 的 BaseValue 一 一 Standard-WrapperValve 中 调用 ， 生 命 周期 相关 的 方法 是 在 Wrapper 的 实现 类 StandardWrapper 中 调用 。 


7.5 ”Connector 分 析 


Connector 用 于 接收 请 求 并 将 请 求 封 装 成 Request 和 Response 来 具体 处 理 ， 最 底层 是 使 用 Socket 来 进行 连接 的 ，Request 和 Response 是 按照 HTTP 协 议 来 封装 的 ， 所 以 Connector 同 时 实现 了 TCP/IP 协 
议和 HTTP 协 议 ，Request 和 Response 封 装 完 之 后 交 给 Container 进 行 处 理 ，Container 就 是 Servlet 的 容器 ，Container 处 理 完 之 后 返回 给 Connector， 最 后 Connector 使 用 Socket 将 处 理 结果 返回 给 客户 
端 ， 这 样 整个 请 求 就 处 理 完 了 。 


7.5.1 ”Connector 的 结构 


Connector 中 具体 是 用 ProtocolHandler 来 处 理 请 求 的 ， 不 同 的 ProtocolHandler 代 表 不 同 的 连接 类 型 ， 比 如 ，Http11Protocol 使 用 的 是 普通 Socket 来 连接 的 ，Http11NioProtocol 使 用 的 是 
NioSocket 来 连接 的 。 


Man 


ProtocolHandler 里 面 有 3 个 非常 重要 的 组 件 : Endpoint、Processor 和 Adapter。Endpoint 用 于 处 理 底层 Socket 的 网 络 连 接 ，Processor 用 于 将 Endpoint 接 收 到 的 Socket 封 装 成 Request,，Adapterf 
于 将 封装 好 的 Request 交 给 Container 进 行 具体 处 理 。 也 就 是 说 Endpoint 用 来 实现 TCP/IP 协 议 ，Processor 用 来 实现 HTTP 协 议 ，Adapter 将 请 求 适 配 到 Servlet 容 器 进行 具体 处 理 。 


Endpoint 的 抽象 实现 AbstractEndpoint 里 面 定义 的 Acceptor 和 AsyncTimeout 两 个 内 部 类 和 一 个 Handler 接 口 。Acceptor 用 于 监听 请 求 ，AsyncTimeout 用 于 检查 异步 request 的 超时 ，Handler 用 于 处 
理 接收 到 的 Socket， 在 内 部 调用 了 Processor 进 行 处 理 。 


Connector 的 结构 如 图 7-6 所 示 。 


Acceptor 


Processor Adapter Container 
Handler 


Async[limeout 


图 7-6 ”Connector 结 构 关 系 图 


7.5.2 ”Connector 自 身 类 


Connector 类 本 身 的 作用 主要 是 在 其 创建 时 创建 ProtocolHandler， 然 后 在 生命 周期 的 相关 方法 中 调用 了 ProtocolHandler 的 相关 生命 周期 方法 。Connector 的 使 用 方法 是 通过 Connector 标 签 配置 在 
conf/serverxml 文 件 中 ， 所 以 Connector 是 在 Catalina 的 load 方 法 中 根据 conf/server.xm| 配 置 文件 创建 Server 对 象 时 创建 的 。Connector 的 生命 周期 方法 是 在 service 中 调用 的 。 


Connector 的 创建 


Connector 的 创建 过 程 主要 是 初始 化 ProtocolHandler。server.xm 配 置 文件 中 Connector 标 签 的 protocol 属 性 会 设置 到 Connector 构 造 函 数 的 参数 中 ， 它 用 于 指定 ProtocolHandler 的 类 
型 ，Connector 的 构造 函数 代码 如 下 : 


// org.apache.catalina.connector.Connector 
public Connector (String protocol) { 
// 根 据 protocol 参 数 指定 protocolHandlerClassName 
setProtocol (protocol); 
// 实例 化 ProtocolHandler 
ProtocolHandler p = null; 


try { 
Class<?> clazz = Class.forName (protocolHandlerClassName); // 初 始 化 代码 
P = (ProtocolHandler) clazz.newInstance(); 


} catch (Exception e) { 
log.error (sm.getString( 
"coyoteConnector.protocolHandlerInstantiationFailed"), e); 
} finally { // 赋值 给 protocolHandler 属 性 
this.protocolHandler = p; 


} 
if (!Globals.STRICT SERVLET COMPLIANCE) { 

URIENcoding = "UTF-8"; 

URIENcodingLower = URIEncoding.toLowerCase (Locale.ENGLISH); 
} 


这 里 首先 根据 传 入 的 protocol 参 数 调 用 setProtoco| 方 法 设置 了 protocolHandlerClassName 属 性 ， 接 着 用 protocolHandlerClassName 所 代表 的 类 创建 了 ProtocolHandler 并 赋值 给 了 protocol- 
Handler 属 性 。 


设置 protocolHandlerClassName 属 性 的 setProtoco| 方 法 代码 如 下 : 


// org.apache.catalina.connector.Connector 
public void setProtocol (String Protocol) { 
if (AprLifecycleListener.isAprAvailable()) { 
if ("HTTP/1.1".equals (protocol)) { 
setProtocolHandlerClassName 


("org.apache.coyote.http11.HLtPp11APrProtocol") 
} else if ("AJP/1.3".equals (Protocol)) { 
setProtocolHandlerClassName 
("org.apache.coyote.ajp.AjpAprProtocol1"); 


} else if (protocol != null) { 
setProtocolHandlerClassName (protocol); 
} else { 


setProtocolHandlerClassName 
("org.apache.coyote.httpl]1.HttpllAprProtocol"); 
} 
} else { 
if ("HTTP/1.1".equals (Protocol)) { 
setProtocolHandlerClassName 
("org.apache.coyote.httpl]1 .HttpllNioProtocol"); 
} else if ("AJP/1.3".equals (Protocol)) { 
setProtocolHandlerClassName 
("org.apache.coyote.ajp.AjpNioProtocol"); 
} else if (protocol != null) { 
setProtocolHandlerClassName (protocol); 


} 


的 一 个 运行 时 环境 ， 如 果 要 使 用 Apr 需 要 先 安 装 ， 安 装 后 Tomcat 可 以 自己 检测 出 来 。 如 果 安 装 了 Apr，setProtoco 上 方法 会 根据 配置 的 


Apr 是 Apache Portable Runtime 的 缩写 ， 是 Apache 提 供 
居 配 置 的 HTTP/1.1 属 性 将 protocolHandler-ClassName 设 置 为 


HTTP/1.1 属 性 对 应 地 将 protocolHandlerClassName 设 置 为 org.apache.coyote.http11.Http11AprProtocol， 如 果 没有 安装 Apr， 会 根 
org.apache.coyote.http11.Http11NioProtocol， 然 后 就 会 根据 protocol-Handler ClassName 来 创建 ProtocolHandler。 


Connector 生 命 周期 处 理 方法 


Connector 的 生命 周期 处 理 方法 中 主要 调用 了 ProtocolHandler 的 相应 生命 周期 方法 ， 代 码 如 下 : 


// org.apache.catalina.connector.Connector 
protected void initInternal () throws LifecycleException { 
super.initIinternal (); 
// 新 建 Adapter， 并 设置 到 protocolHandler 
adapter = new CoyoteAdapter (this); 
protocolHandler. setAdapter (adapter); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/15447/O0EBPS/Text/... 
try { 
、 // 初始 化 protocolHandler 
protocolHandler.init (); 
} catch (Exception e) { 
throw new LifecycleException 
(sm.getString 
("coyoteConnector.protocolHandlerInitializationFailed"), e); 


} 


QOverride 
protected void startInternal () throws LifecycleException { 
if (getPort() < 0) { 
throw new LifecycleException (sm.getString( 
"CoyoteConnector.invalidPort", Integer.valueOf (getPort () ) ) ) 7 
setState (LifecycleState.STARTING) 7 
try { 
protocolHandler .start (); 
} catch (Exception e) { 
String errPrefix = ""; 
if (this.service != null) { 
errPrefix += "service.getName(): \"" + this.service.getName() + "N"7 "; 


} 


throw new LifecycleException 
(errPrefix + " " + sm.getString 
("coyoteConnector .protocolHandlerstartFailed"), e); 


} 
} 
QOverride 
protected void stopInternal () throws LifecycleException { 
SetState (LifecycleState.STOPPING); 
try { 
protocolHandler. stop (); 
} catch (Exception e) { 
throw new LifecycleException 
(sm.getString 


("coyoteConnector .protocolHandlerStopFailed"), e); 
} 
} 
QOverride 
protected void destroyInternal () throws LifecycleException { 
try { 


protocolHandler .destroy () 7 
} catch (Exception e) { 

throw new LifecycleException 

(sm.getString 
("coyoteConnector .ProtocolHandlerDestroyFailed")，e) 7 

} 
if (getService() != null) { 

getService () .removeConnector (this); 


} 


super.destroyInternal (); 


在 initinternal 方 法 中 首先 新 建 了 一 个 Adapter 并 设置 到 ProtocolHandler 中 ， 然 后 对 ProtocolHandler 进 行 初始 化 ;在 startinternal 方 法 中 首先 判断 设置 的 端口 是 否 小 于 0， 如 果 小 于 0 就 抛 出 异常 ， 否 则 
就 调用 ProtocolHandler 的 start 方 法 来 启动 ;在 stoplnternal 方 法 中 先 设 置 了 生命 周期 状态 ， 然 后 调用 了 ProtocolHandler 的 stop 方 法 ; 在 destroyInternal 方 法 中 除了 调用 ProtocolHandler 的 destroy 方 
法 ， 还 会 将 当前 的 Connector 从 Service 中 删除 并 调用 父 类 的 destroylnternal 方 法 。 


7.5.3 ProtocolHandler 


7-7 所 示 。 


[ 


Tomcat 中 ProtocolHandler 的 继承 结构 如 


a ProtocolHandler 
a BO Abstractprotocc|<S> 
a BO" AbstracthjpProtocol<S$» 
BB AjpAprProtocol 
© AjpNio2Protocol 
四 AjpNicoprotocol 
回 AjpProtocol 


a BO* AbstractHttpllprotoco|<S> 
a OB* AbstractHttpliljsseprotoco|<S> 
BB HtpliNis2Protecel 
BB |HttpliNiePratecal 
© HttpllProtocel 
OB HttpllAprProtocol 
3 SpdyProxyProtoco| 


图 7-7 ”ProtocolHandler 继 承 结构 


ProtocolHandler 有 一 个 抽象 实现 类 AbstractProtocol，AbstractProtocol 下 面 分 了 三 种 类 型 : Ajp、HTTP 和 Spdy。Ajp 是 Apache JServ Protocol 的 缩写 ，Apache 的 定向 包 协 议 ， 主 要 用 于 与 前 端 服 
务 器 (如 Apache) 进行 通信 ， 它 是 长 连接 ， 不 需要 每 次 通信 都 重新 建立 连接 ， 这 样 就 节省 了 开销 ; HTTP 协 议 前 面 已 经 介绍 过 了 ， 就 不 重复 介绍 了 ; Spdy 协 议 是 Google 开 发 的 协议 ， 作 用 类 似 HTTP， 比 
HTTP 效 率 高 ， 不 过 这 只 是 Google 制 定 的 企业 级 协议 ， 使 用 并 不 广泛 ， 而 且 在 HTTP/2 协 议 中 已 经 包含 了 Spdy 所 提供 的 优势 ， 所 以 Spdy 协 议 平常 很 少 使 用 ， 不 过 Tomcat 提 供 了 支持 。 


这 里 的 ProtocolHandler 以 默认 配置 中 的 org.apache.coyote.http11.Http11NioProtoco 为 例 来 分 析 ， 它 使 用 HTTP1.1 协 议 ，TCP 层 使 用 NioSocket 来 传输 数据 。 


Http11NioProtocol 的 构造 函数 中 创建 了 NioEndpoint 类 型 的 Endpoint， 并 新 建 了 Http11-ConnectionHandler 类 型 的 Handler 然 后 设置 到 了 Endpoint 中 ， 代 码 如 下 : 


// org.apache.coyote .http11.Http11NioProtocol 

Public HttpllNioProtocol() { 
endpoint=new NioPndpoint (); 
cHandler = new HttpllConnectionHandler (this); 
( (Niogndpoint) endpoint) .setHandler (cHandler); 
setSoLinger (Constants.DEFAULT CONNECTION LINGER); 
setSoTimeout (Constants .DEFAULT CONNECTION TIMEOUT); 
setTcpNoDelay (Constants.DEFAUIT TCP NO DELAY); 


四 个 生命 周期 方法 是 在 父 类 AbstractProtocol 中 实现 的 ， 其 中 主要 调用 了 Endpoint 的 生命 周期 方法 。 


7.5.4 处 理 TCPV/IP 协 议 的 Endpoint 


Endpoint 用 于 处 理 具体 连接 和 传输 数据 ，NioEndpoint 继 承 自 org.apache.tomcat.utilnet.AbstractEndpoint， 在 NioEndpoint 中 新 增 了 Poller 和 SocketProcessor 内 部 类 ，NioEndpoint 中 处 理 请 求 
的 具体 流程 如 图 7-8 所 示 。 


NioEndpoint 的 init 和 start 方 法 在 父 类 AbstractEndpoin 中 ， 代 码 如 下 : 


Processor 


图 7-8 NioEndpoint 处 理 请 求 流程 图 


// org.apache.tomcat.util.net.AbstractEndpoint 
public final void init() throws Exception { 
if (bindonInit) { 
bind(); 
bindState = BindState.BOUND ON_INIT; 
Ek 
} 
public final void start() throws Exception { 
if (bindState == Bindstate.UNBOUND) { 
bind(); 
bindstate = BindState.BOUND ON_START; 
} 
startIinternal (); 


这 两 个 方法 主要 调用 bind 和 startinternal 方 法 ， 它 们 是 模板 方法 ， 在 NioEndpoint 中 实现 ，bind 方 法 代码 如 下 : 


// org.apache.tomcat .util.net.Niogndpoint 
public void bind() throws Exception { 
serverSock = ServerSocketChannel .open () 7 


socketProperties.setProperties (serverSock.socket ()); 


InetSocketAddress addr = (getAddress() !=null?new InetSocketAddress (getAddress () ,getPort () ) :new InetSocketAddress (getPort ())); 


serverSock.socket () .bind (addr, getBacklog ()); 
serverSock.configureBlocking (true); 


serverSock. socket () .setSoTimeout (getSocketProperties () .getSoTimeout ()); 


// 初始 化 需要 启动 acceptor 线 程 的 个 数 ， 如 果 为 0 则 改 为 1， 否 则 将 不 能 工作 


if (acceptorThreadCount 一 0) { 
acceptorThreadCount = 1; 


} 
// 初始 化 需要 启动 Poller 线 程 的 个 数 ， 如 果 小 于 等 于 0 则 改 为 1 


if (pollerThreadCount <= 0) { 
pollerThreadCount = 1; 


i 


stopLatch = new CountDownLatch (pollerThreadCount); 


// 如 果 需 要 则 初始 化 SSL 
if (isSSLEnabled()) { 


SSLUtil sslUtil = handler.getSs1Implementation() .getSSLUtil (this); 


sslContext = sslUtil.createSSLContext () 7 


sslContext .init (wrap (sslUtil .getKeyManagers ()),sslUtil.getTrustManagers(), null); 
SSLSessionContext sessionContext =sslContext .getServerSessionContext (); 


if (sessionContext != null) { 


sslUtil.configureSessionContext (sessionContext); 


} 


enabledCiphers = sslUtil.getEnableableCiphers (sslContext); 


enabledProtocols = sslUtil.getEnableableProtocols (sslContext); 


} 
if (oomParachute>0) reclaimParachute (true); 
selectorPool .open () 7 


这 里 的 bind 方 法 中 首先 初始 化 了 ServerSocketChannel， 然 后 检查 了 代表 Acceptor 和 Poller 初 始 化 的 线程 数量 的 acceptorThreadCount 属 性 和 pollerThreadCount 属 性 ， 它 们 至 少 为 1，Acceptor 用 于 
接收 请 求 ， 接 收 到 请 求 后 交 给 Poller 处 理 ， 它 们 都 是 启动 线程 来 处 理 的 。 另外 还 处 至 


NioEndpoint 的 startlnternal 方 法 代码 如 下 : 


有 了 初始 化 SSL 等 内 容 。 


// org.apache.tomcat.util.net.Niogndpoint 
QOverride 
public void startInternal () throws Exception { 
if (!running) { 
running = true; 
Paused = false; 


processorCache = new SynchronizedStack<>(SynchronizedStack.DEFAULT SIZE,socketProperties.getProcessorCache () ) 7 
keyCache = new SynchronizedStack<> (SynchronizedStack.DEFRULT SITZE, SocketProperties.getKeyCache () ) 7 
eventCache = new SynchronizedStack<> (SynchronizedStack.DEFAULT SIZE, socketProperties .getEventCache () ) 


nioChannels = new SynchronizedStack<> (SynchronizedSstack.DEFAULT SIZE, socketProperties.getBufferPool ()); 


// 创建 Executor 

if ( getExecutor() 一 null ) { 
createExecutor (); 

} 

initializeConnectionLatch ()7 

// 启 动 Pollez 线 程 


pollers = new Poller[getPollerThreadCount () ] 7 


for (int i=0; i<pollers.length; i++) { 
pollers[i] = new Poller(); 


Thread pollerThread = new Thread(pollers[i], getName() + "-ClientPoller-"+i); 


pollerThread. setPriority (threadPriority); 


pollerThread. setDaemon (true); 
pollerThread. start (); 

} 

startAcceptorThreads (); 


这 里 首先 初始 化 了 一 些 属性 ， 然 后 启动 了 Poller 和 Acceptor 来 处 理 请 求 ， 初 始 化 的 属性 中 的 processorCache, 


属性 是 SynchronizedStack<SocketProcessor> 类 型 ，SocketProcessor 并 不 是 前 面 介绍 的 


Processor， 而 是 NioEndpoint 的 一 个 内 部 类 ，Poller 接 收 到 请 求 后 就 会 交 给 它 处 理 ，SocketProcessor 又 会 将 请 求 传递 到 Handler。 启 动 Acceptor 的 startAcceptorThreads 方 法 在 AbstractEndpoint 中 , 代 
码 如 下 : 


// org.apache.tomcat .util.net.AbstractEndpoint 
protected final void startAcceptorThreads() { 
int count = getAcceptorThreadCount (); 

acceptors new Acceptor[count]; 
for (int i = 0; i < count; i++) { 
acceptors[i] = createAcceptor () 7 


String threadName = getName () + "-Acceptor-" + i; 


acceptors[il] .setThreadName (threadName); 


Thread 七 = new Thread(acceptors[i], threadName); 


t.setPriority (getAcceptorThreadPriority()); 
t.setDaemon (getDaemon () ) 7 
tstart (); 


这 里 的 getAcceptorThreadCount 方 法 就 是 获取 的 init 方 法 中 处 理 过 的 acceptorThreadCount 属 性 ， 获 取 到 后 就 会 启动 相应 数量 的 Acceptor 线 程 来 接收 请 求 。 


7.5.5 ”处 理 HTTP 协 议 的 Processor 


Processor 用 于 处 理应 用 层 协议 (如 HTTP) ， 它 的 继承 结构 如 图 7-9 所 示 。 


a I Processor<S> 

4 (3° AbstractProcessor<S» 
AprProcessor 
BioProcessor Upgrade 
Nio2Processor 

] NioProcessor 

4 BB" AbstractProcessor<S> 

4 四 "AbstractAjpprocessor<S> 

四 内 pAprprocessor 


回 AjpNio2Processor 
加 AjpNioProcessor 
四 内 ppProcessor 
a OB Abstra ctHttpllProcessor<Ss> 
加 HttpllAprProcessor 
Httpl1Nio2Processor 
HitpllNioProcessor 


HttpllProcessor 


3 spdyProcessor=<S> 


图 7-9 ”Processor 的 继承 结构 图 


Processor 有 两 个 AbstractProtocol 抽 象 继承 类 ， 图 7-9 中 上 面 的 AbstractProtocol 是 在 org.apache.coyote.http11.upgrade 包 中 ， 下 面 的 AbstractProtocol 在 org.apache.coyote 包 中 。 正 常 处 理 协 议 
使 用 的 是 下 面 的 AbstractProtocol 及 其 实现 类 ， 上 面 的 AbstractProtocol 是 Servlet3.1 之 后 才 新 增 的 ， 用 于 处 理 HTTP 的 升级 协议 ， 当 正常 (下面) 的 Processor 处 理 之 后 如 果 Socket 的 状态 是 
UPGRADING， 那 么 Endpoint 中 的 Handler 将 会 接着 创建 并 调用 org.apache.coyote.http11.upgrade 包 中 的 Processor 进 行 处 理 ， 这 里 的 HTTP 升 级 协议 指 的 是 WebSocket 协 议 。 


图 7-9 中 下 方 org.apache.coyote 包 中 的 Processor 和 前 面 介 绍 过 的 ProtocolHandler 一 一 对 应 ， 这 里 就 不 详细 解释 了 ， 具 体 实 现 应 用 层 协议 处 理 请 求 的 是 AbstractAjpProcessor 和 Abst- 


ractHttp11Processor 中 的 process 方 法 ， 这 个 方法 中 首先 封装 了 Request 和 Response， 然 后 调用 Adapter 将 请 求 传递 到 了 Container 中 ， 最 后 对 处 理 的 结果 进行 了 处 理 ， 如 有 没有 启动 异步 处 理 、 处 理 过 程 
中 有 没有 抛 出 异常 等 。 


7.5.6 ”适配器 Adapter 


Adapter 只 有 一 个 实现 类 ， 那 就 是 org.apache.catalina.connector 包 下 的 CoyoteAdapter 类 。Processor 在 其 process 方 法 中 会 调用 Adapter 的 service 方 法 来 处 理 请 求 ，Adapter 的 service 方 法 主要 是 调 
Container 管 道中 的 invoke 方 法 来 处 理 请 求 ， 在 处 理 之 前 对 Request 和 Response 做 了 处 理 ， 将 原来 创建 的 org.apache.coyote 包 下 的 Request 和 Response 封 装 成 了 org.apache.catalina.connector 的 
Request 和 Response， 并 在 处 理 完成 后 判断 是 否 启动 了 Comet (长 连接 推 模式 ) 和 是 否 启动 了 异步 请 求 ， 并 作出 相应 处 理 。 调 用 Container 管 道 的 相应 代码 片段 如 下 : 


// org.apache.catalina.connector.CoyoteAdapter .process 
Connector .getService () .getContainer () .getPipeline () .getFirst () .invoke (request, response); 


这 里 首先 从 Connector 中 获取 到 Service (Connector 在 initlnternal 方 法 中 创建 Coyote-Adapter 的 时 候 已 经 将 自己 设置 到 了 CoyoteAdapter 中 ) ， 然 后 从 Service 中 获取 Container， 接 着 获取 管道 ， 再 
获取 管道 的 第 一 个 Value， 最 后 调用 invoke 方 法 执行 请 求 。Service 中 保存 的 是 最 顶层 的 容器 ， 当 调用 最 顶层 容器 管道 的 invoke 方 法 时 ， 管 道 将 逐 层 调用 各 层 容器 的 管道 中 Value 的 invoke 方 法 ， 直 到 最 后 调 
Wrapper 的 管道 中 的 BaseValue (StandardWrapperValve) 来 处 理 Filter 和 Servlet。 


第 二 篇 ”俯视 Spring MVC 


Spring MVC 的 本 质 其 实 就 是 一 个 Servlet， 本 篇 将 从 顶层 分 析 Spring MVC 的 结构 ， 让 大 家 对 Spring MVC 有 个 整体 的 认识 。 


对 一 个 框架 的 学 习 ， 首 先 要 知道 怎么 用 ， 然 后 才 好 进行 分 析 。 由 于 Spring MVC 的 结构 比较 复杂 ， 所 以 对 其 分 析 需 要 有 一 定 的 策略 ， 否 则 很 容易 陷 到 具体 的 细节 里 面 ， 感 觉 代码 大 概 也 能 看 明白 ,但 具体 
怎么 回 事 也 说 不 清 。 


古人 说 “ 工 欲 善 其 事 ， 必 上 先 利 其 器 ”， 我 们 要 分 析 的 Spring MVC 就 是 这 么 一 个 器 。 首 先 Spring MVC 是 一 个 工具 ， 然 后 才能 用 来 干 活 ， 既 然 是 个 工具 ， 首 先 就 要 将 其 制造 (创建 ) 出 来 ， 然 后 才 可 以 用 它 
干 活 ， 所 以 Spring MVC 的 代码 可 以 分 成 两 步 来 进行 分 析 ， 第 一 步 分 析 Spring MVC 是 怎么 创建 出 来 的 ， 第 二 步 分 析 它 是 怎么 干 活 的 。 这 种 方法 可 以 在 一 个 复杂 的 类 的 很 多 看 似 杂 乱 无 章 的 方法 中 快速 梳理 出 头 
绪 ， 所 以 它 不 仅 可 以 用 于 分 析 Spring MVC 的 源码 ， 分 析 别 的 源码 也 可 以 使 用 ， 特 别 是 分 析 一 些 复 杂 源 码 的 时 候 。 


本 书 不 仅 是 在 分 析 Spring MVC 整 体 结构 时 用 了 这 种 思路 ， 在 后 面 分 析 组 件 的 过 程 中 也 还 会 有 很 多 地 方 使 用 这 种 思路 。 为 了 方便 称呼 ， 就 将 要 分 析 的 目标 叫 作 “ 器 ”， 用 法 叫 作 “ 用 ”， 先 分 析 “ 器 ”的 
创建 再 分 析 “ 用 ”的 方法 的 分 析 法 称 为 “器 用 分 析 法 ”。 


本 篇 一 共有 3 章 内 容 : 
Spring MVC 之 初 体验 : 搭建 环境 并 介绍 简单 的 使 用 方法 。 
* 创建 Spring MVC 之 器 : 分 析 Spring MVC 本 身 的 创建 过 程 。 


' SpringMVC 之 用 : 分 析 Spring MVC 如 何 工 作 。 


第 8 章 Spring MVC 之 初 体验 


本 章 将 带 大 家 把 环境 建 起 来 ， 然 后 通过 一 个 简单 的 例子 体验 Spring MVC 是 怎么 用 的 。 


8.1 “环境 搭建 


Spring MVC 的 环境 搭建 非常 简单 ， 首 先 建 一 个 web 项 目 ， 如 果 是 maven 项 目 ， 只 需要 简单 地 加 入 Spring MVC 和 Servlet 的 依赖 就 可 以 了 (Tomcat8 默 认 使 用 的 是 Servlet3.1，Tomcat7 默 认 使 用 的 是 
Servlet3.0) 。 


<dependency> 
<groupId>javax.servlet</groupId> 
<artifactId>javax.servlet-api</artifactId> 
<version>3.1.0</version> 
<scope>provided</scope> 

</dependency> 

<dependency> 
<groupId>org.springframework</groupId> 
<artifactId>spring-webmvc</artifactId> 
<version> 4.1.5.RELEASE</version> 

</dependency> 


如 果 没 用 使 用 maven， 将 图 8-1 所 示 的 包 下 载 后 放 入 WEB-INF/lib 目 录 下 就 可 以 了 。 


aopalliance-1.0.Jar 


commons-logging-1. 


2,jar 


spnng-aop-4,.1.5,RELEASE,Jar 
spring-beans-4.1.5.RELEASE.Iar 
spring-context-4.1.5,RELEASE,jar 


spring-core-4.1.5.RELEASE.ar 
spring-expression-4.1.5.RELEASE,ar 
spring-web-4.1,5,RELEASE,ar 
spring-webmvc-4.1.5.RELEASE,Jar 


图 8-1 SpringMVC 最 小 依赖 包 


8.2 Spring MVC 最 简单 的 配置 


配置 一 个 Spring MVC 只 需要 三 步 : @ 在 web.xml 中 配置 Servlet; @ 创 建 Spring MVC 的 xml 配 置 文件 ，@ 创 建 Controller 和 view。 下 面 分 别 介绍 。 


8.2.1 在 web.xml 中 配置 Servlet 


<?xml Version="1.0" encoding="UTF-8"?> 
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
http://xmlns.jcp.org/xml/ns/javaee/web-app_ 3_1.xsd" 
version="3.1"> 
<!-- spring mvc 配 置 开始 --> 
<servlet> 
<servlet-name>let'sGo</servlet-name> 


<servlet-class>org.springframework.web.servlet .DispatcherServlet</servlet-class> 
<load-on-startup>1</lo0ad-on-startup> 
</servlet> 
<servlet-mapping> 
<servlet-name>let'sGo</servlet-name> 
<url-pattern>/</url-pattern> 
</servlet-mapping> 
<!-- spring mvc 配 置 结束 -> 
<welcome-file-list> 
<welcome-file>index</welcome-file> 
</welcome-file-list> 
</web-app> 


这 里 配置 了 一 个 叫 let 抒 o 的 Servlet， 自 动 启动 ， 然 后 mapping 到 所 有 的 请 求 。 所 配置 的 Servlet 是 DispatcherServlet 类 型 ， 它 就 是 Spring MVC 的 入 口 ，Spring MVC 的 本 质 就 是 一 个 Servlet。 在 配置 


DispatcherServlet 的 时 候 可 以 设置 contextConfigLocation 参 数 来 指定 Spring MVC 配 置 文件 的 位 置 ， 如 果 不 指定 就 默认 使 ， 
INF/let'sGo-servlet.xm| 文 件 。 


8.2.2 ”创建 Spring MVC 的 xml 配 置 文件 


首先 在 WEB-INF 目 录 下 新 建 let”sGo-servlet.xml 文 件 ， 然 后 使 用 Spring MVC 最 简单 的 配置 方式 来 进行 配置 。 


WEB-INF/[ServletName]-servlet.xml 文 件 ， 这 里 使 


了 默认 值 ， 也 就 是 WEB- 


<!--WEB-INF/let'sGo -servlet .xml --> 
<?xml Version="1.0" encoding="UTF-8"?> 
<beans xmlns="http://www.springframework.org/schema/beans" 


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"™" 
xmlns:p="http://www.springframework.org/schema/p" 
xmlns:context="http://www.springframework.org/schema/context" 
xmlns:mve="http://www.springframework.org/schema/mve" 
xsi:schemaLocation="http://www.springframework.org/schema/beans 
http://www.springframework.org/schema/beans/spring-beans.xsd 
http://www.springframework.org/schema/context 
http://www.springframework.org/schema/context/spring-context .xsd 
http://www.springframework.org/schema/mve 
http://www.springframework.org/schema/mvc/spring-mvc.xsd"> 
<mvc:annotation-driven/> 
<context :component-scan base-package="com.excelib" /> 
</beans> 


<mvcannotation-driven/> 是 Spring MVC 提 供 的 一 键 式 的 配置 方法 ， 配 置 此 标签 后 Spring MVC 会 帮 有 我 们 自动 做 一 些 注册 组 件 之 类 的 事情 。 这 种 配置 方法 非常 简单 ，<mvc:-annotation-driven/> 背 
后 的 原理 会 在 后 面 详细 解释 。 另 外 还 配置 了 context:component-scan 标 签 来 扫描 通过 注释 配置 的 类 ， 如 果 使 用 了 Spring 可 以 通过 context:include-filter 子 标签 来 设置 只 扫描 @Controller 就 可 以 了 ， 别 的 交 
给 Spring 容 器 去 管理 ， 不 过 这 里 只 配置 了 Spring MVC， 所 以 就 全 部 放 到 Spring MVC 里 了 。 只 扫描 @Controller 的 配置 如 下 : 


<context :component-scan base-package="com.excelib" use-default-filters="false"> 
<context:include-filter type="annotation"expression="org.springframework.stereotype.Controller" /> 
</context :component-scan> 


8.2.3 创建 Controller 和 view 


到 现在 Spring MVC 的 环境 就 已 经 搭建 完成 了 。 下 面 写 个 Controller 和 View， 这 样 就 可 以 运行 了 。 


首先 在 com.excelib.controller 包 下 建 一 个 类 一 一 GoController。 


package com.excelib.controller; 
import org.apache.commons.1logging.Log; 
import org.apache.commons.1logging.LogFactory; 
import org.springframework.stereotype.Controller; 
import org.springframework.ui.Model; 
import org.springframework.web.bind.annotation.RequestMapping; 
import org.springframework.web.bind.annotation.RequestMethod; 
Q@Controller 
Public class GoController { 
private final Log logger = LogFactory.getLog (GoController.class); 
// 处 理 HEAD 类 型 的 ”/” 请 求 
@RequestMapping (value={"/"},method= {RequestMethod.HEAD}) 
public String head() { 
return "go.jsp"; 


} 
// 处 理 GET 类 型 的 "/index" 和 ”/” 请 求 
@RequestMapping (value={"/index","/"},method= {RequestMethod.GET}) 
public String index (Model model) throws Exception { 
logger .info ("======processed by index==—==-=="); 
// 返 回 msg 参 数 
model.addAttribute ("msg"，"Go Go Go!"); 
return "go.jsp"; 


这 里 单独 写 了 处 理 HEAD 请 求 的 方法 ， 此 方法 可 以 用 来 检测 服务 器 的 状态 ， 因 为 它 不 返回 body 所 以 比 GET 请 求 更 节省 网 络 资源 。 而 单独 写 一 个 处 理 方法 而 不 跟 GET 请 求 使 用 同一 个 方法 ， 然 后 返回 没有 
Body 的 Response 是 因为 GET 请 求 的 处 理 过 程 可 能 会 处 理 一 些 别 的 内 容 ， 如 初始 化 一 些 首页 需要 显示 的 内 容 ， 还 可 能 会 连接 数据 库 ， 而 这 些 都 比较 浪费 资源 ， 并 且 对 于 HEAD 请 求 来 说 也 是 不 需要 的 ， 所 以 最 
好 单独 写 一 个 方法 。 


如 果 没 有 配置 ViewResolver，Spring MVC 将 默认 使 用 org.springframework.web.servlet.view.InternalResourceViewResolver 作 为 ViewResolver， 而 且 prefix 和 suffix 都 为 空 。 所 以 go.jsp 返 回 值 对 
应 的 就 是 根 目录 下 的 gojsp 文 件 。 我 们 就 把 它 建 出 来 。 


<%@ page contentType="text/html;charset=UTF-8" language="java" %> 
<html> 
<head> 
<title> let'sGo</title> 
</head> 
<body> 
${msg} 
</body> 
</html> 


好 了 ， 现 在 编译 后 部 署 到 Tomcat 就 可 以 运行 了 ， 运 行 结果 如 图 8-2 所 示 。 


| let'sGo 


© 2G DB localhost:8080 


go Go Gol! 


图 8-2 ”运行 结果 图 


8.3 ”关联 spring 源 代码 


到 这 里 Spring MVC 的 一 个 简单 的 例子 就 做 完了 ， 下 面 将 spring 的 源 代码 关联 上 去 。 在 关联 之 前 首先 需要 将 代码 下 载 到 本 地 。Spring 源 码 的 下 载 地 址 是 http://repo.spring.io， 打 开 后 点 击 Artifacts 选 项 
卡 ， 然 后 在 右上 角 的 搜索 框 输入 spring-framework-4.1.5.RELEASE 进 行 搜索 (图 8-3) ， 在 搜索 结果 (图 8-4) 中 下 载 spring-framework-4.1.5.RELEASE-dist.zip 就 可 以 了 。 


Spring-framework-t.15 RE 证 


Repository Browser 


Dextreleaseoca General 

» 所 sxi-snapshoi-local 

» tO install 

» a libs-milestone-loca| Info 

» 久 libs-release-loca| Name: ext-release-local (7 

*， 对 libs-snapshot-continuous-loca Descriplion- Local repository for third party libraries (i.e. those unavailable in any msven repository) 
» ta libs-snapshat-local Croatod: 05-05-13 12:25:04 UTC (672d 13h 24m 10s 2g0) 和 

» 人 1ibs-staging-local 

» 扩 plugins-release-local 
» 伟 plugins-snapshot-local 
} 锚 asciidoctor-cache 

， 六 clouderacache 

， 大 codehaus-cache 

» 外 conjars-release-cache 
， 合 conjars-snapshotcache 因 Refresh 
;总 ebrbuild-plugins-cache 

» 总 sbrmaven-extemal-cache 
上 宣 Eclpselnk-cache Virtual Repository Associations 

» 芒 gemstone-release-Cache 忆 repo 和 libs-rslease 幸 libs-milestone 赂 ibs-snapshot 绊 plugins-release 忆 plugins-snapshot 


奢 googlecode-cache 
+» 车 gradle-libs-cache 


Artifact Count- Show... 
Repository Path- ext-release-local: 所 


Repository Layoul: maven-2-default 


Actions 


口 Compact empty folders 


图 8-3 ”搜索 spring 包 网 页 界面 


(3 |spring-framework-4.15 RELEA: 性 


>» Limit Search to Specific Repositories 吧 


6 matches found for "spring-framework-4.1.5.RELEASE' (2 ms) 


A -0 A) 


-dist zip.asc 


|spring-framework-4.1.5.RELEASE 
|spring-framework-4.1.5.RELEASE-docs zip 


| spring-framework-4.1.5.RELEASE-docs zip.asc 


|spring-fframework-4.1.5.RELEASE-schema zip 


spring-framework-4.1.5.RELEASE-schema.zip.asc 


图 8-4 下载 spring 包 网 页 界面 


下 载 后 压缩 包 的 libs 目 录 下 以 -sources 结 尾 的 jar 包 就 是 源码 (图 8-5) ， 然 后 将 其 关联 到 IDE 就 可 以 了 。 


如 果 使 用 的 是 MyEclipse， 在 Web App Libraries (如 果 使 用 了 maven 是 Maven Depen-dencies) 目录 下 找到 需要 关联 源码 的 包 ， 点 击 右键 找到 最 下 面 的 properties， 在 打开 的 对 话 框 中 的 右 侧 选择 


External location， 然 后 点 击 Extenrnal File... 按 钮 ， 选 择 下 载 好 的 源码 文件 关联 就 可 以 了 ， 如 图 8-6 和 图 8-7 所 示 。 


国 spring-aop-4.1.5,RELEASE.jar 

国 spring-aop-4.1.5.RELEASE-javadoc.jar 

回 spring-aop-4.1.5.RELEASE -Sourcesjar 

回 spring-aspects-4.1.5.RELEASE jar 

固 spring-aspects-4.1.5.RELEASE-javadocjar 

加 spring-aspects-4,1.5.RELEASE-sources.jar 

I® spring-beans-4.1,.5.RELEASE.jar 

国 spring-beans-4.1.5.RELEASE-javadoc.jar 

四 spring-beans-4.1.5.RELEASE-sources.jar 

国 spring-context-4.1.5.RELEASE.jar 

回 spring-context-4.1.5.RELEASE-javadocjar 

回 spring-context-4.1.5.RELEASE-sourcesjar 

国 spring-context-support-4.1.5.RELEASE jar 

回 spring-context-support-4.1.5.RELEASE-javadocjar 
回 spring-context-support-4.1.5.RELEASE-sourcesjar 
回 spring-core-4.1.5.RELEASE jar 

回 spring-core-4.1.5.RELEASE-javadocjar 

4 


图 8-5 spring 源码 位 置 图 


大 小 


350.68 KB 


815.07 KB 
345.41 KB 
55.49 KB 
61.96 KB 
33.57 KB 
691.90 KB 
135 MB 
656.45 KB 
1002.45 KB 
2.30 MB 
1003.96 KB 
173.93 KB 
421.90 KB 
172.07 KB 
984.58 KB 
1.29 MB 


308.76 KB 
781.37 KB 
312.97 KB 
47.37 KB 
55.41 KB 
27.58 KB 
618.97 KB 
1.30 MB 
601.32 KB 
867.35 KB 
2.19 MB 
898.16 KB 
154.84 KB 
403.59 KB 
154.81 KB 
879.56 KB 
1.24 MB 


Exe 
Exe 
Ex 
Exe 
Exe 
Exe 
Exe 
Exe 
Exe 
Exe 
Exe 
Exe 
Exe 


Assign Working Sets. 


aopalliance-1.0,Jar - G:\\ profile As 


commons-logging-1.2,Ja 
spring-aop-4.1.5.RELEAS 
中 spring-beans-4,1.5.RELE 
Spring-context-4,1.5.REL Aspecb Tools 
spring-core-4.1.5.RELEA 因 Preview in Mobile Web Sir 
spnng-expression-4.1.5. 大 MyEclipse 
9 spring-web-4.1,5.RELEA 
spring-webmvc-4.1.5.REL 


Debug As 
Run As 


图 8-6 ”选择 需要 关联 源码 的 jar 包 


Java Source Attachment 


Select the location (folder, JAR or zip) containing the source for 
"spring-"webmve-4.1.5,.RELEASE jar’: 
© Workspace location 


Path: | 


Encoding: Defauk (UTF-8) > 


图 8-7 关联 源码 


8.4 小 结 


本 章 和 大 家 一 起 做 了 个 简单 的 Spring MVC 的 例子 ， 主 要 是 让 不 熟悉 Spring MVC 的 读者 能 对 其 有 一 个 初步 的 体验 ， 然 后 介绍 了 下 载 和 关联 源 代码 的 方法 ， 可 以 为 后 面 的 分 析 做 好 准备 。 


第 9 章 ”创建 Spring MVC 之 器 


本 章 将 分 析 Spring MVC 自 身 的 创建 过 程 。 首 先 分 析 Spring MVC 的 整体 结构 ， 然 后 具体 分 析 每 一 层 的 创建 过 程 。 


9.1 整体 结构 介绍 


Spring MVC 中 核心 Servlet 的 继承 结构 如 图 9-1 所 示 。 


1 
CFrameworkServlet 
C DispatcherServlet 


9-1 Spring MVC 核心 Servlet 结 构图 


可 以 看 到 在 Servlet 的 继承 结构 中 一 共有 5 个 类 ，GenericServlet 和 HttpServlet 在 java 中 ， 前 面 已 经 讲 过 ， 剩 下 的 三 个 类 HttpServletBean、FrameworkServlet 和 DispatcherServlet 是 Spring MVC 中 
的 ， 本 章 主要 讲解 这 三 个 类 的 创建 过 程 。 


这 三 个 类 直接 实现 三 个 接口 : EnvironmentCapable、EnvironmentAware 和 Application-ContextAware。XXXAware 在 spring 里 表示 对 XXX 可 以 感知 ， 通 俗 点 解释 就 是 : 如 果 在 某 个 类 里 面 想 要 使 
spring 的 一 些 东 西 ， 就 可 以 通过 实现 XXXAware 接 口 告诉 spring，spring 看 到 后 就 会 给 你 送 过 来 ， 而 接收 的 方式 是 通过 实现 接口 唯一 的 方法 set-XXX。 比 如 ， 有 一 个 类 想 要 使 用 当前 的 ApplicationContext， 
那么 我 们 只 需要 让 它 实 现 ApplicationContextAware 接 口 ， 然 后 实现 接口 中 唯一 的 方法 void setApplicationContext (ApplicationContext applicationContext) 就 可 以 了 ，spring 会 自动 调用 这 个 方法 将 
applicationContext 传 给 我 们 ， 我 们 只 需要 接收 就 可 以 了 ! 很 方便 吧 ! EnvironmentCapable， 顾 名 思 义 ， 当 然 就 是 具有 Environment 的 能 力 ， 也 就 是 可 以 提供 Environment， 所 以 EnvironmentCapable 
唯一 的 方法 是 Environment getEnvironment()， 用 于 实现 EnvironmentCapable 接 口 的 类 ， 就 是 告诉 spring 它 可 以 提供 Environment， 当 spring 需 要 Environment 的 时 候 就 会 调用 其 getEnvironment 方 法 
跟 它 要 。 


了 解 了 Aware 和 Capable 的 意思 ， 下 面 再 来 看 一 下 ApplicationContext 和 Environment。 前 者 相信 大 家 都 很 熟悉 了 ， 后 者 是 环境 的 意思 ， 具 体 功能 与 之 前 讲 过 的 ServletContext 有 点 类 似 。 实 际 上 在 
HttpServletBean 中 Environment 使 用 的 是 Standard-Servlet-Environment (在 createEnvironment 方 法 中 创建 ) ， 这 里 确实 封装 了 ServletContext， 同 时 还 封装 了 ServletConfig、JndiProperty、 系 统 环 
境 变 量 和 系统 属性 ， 这 些 都 封装 到 了 其 propertySources 属 性 下 。 为 了 让 大 家 理解 得 更 深刻 ， 在 前 面 项 目的 GoController 中 获取 Environment， 然 后 通过 调试 看 一 下 。 首 先 让 GoController 实 现 
EnvironmentAware 接 口 ， 这 样 spring 就 会 将 Environment 传 给 我 们 ， 然 后 在 处 理 请 求 的 方法 中 加 入 断 点 ， 这 样 就 可 以 查看 spring 传 进来 的 内 容 了 。 修 改 后 代码 如 下 : 


Package com.excelib.controller; 
// 省 略 了 :imports 
Q@Controller 
public class GoController implements EnvironmentAware { 
private final Log logger = LogFactory.getLog (GoController.class); 
@RequestMapping (value={"/"},method= {RequestMethod.HEAD}) 
public String head() { 
return "go.jsp"; 
} 
@RequestMapping (value={"/index","/"},method= {RequestMethod.GET}) 
Public String inde del model) throws E ion { 
logger .info ("= =processed by index: eH 
// 这 里 设置 断 点 
model .addAttribute ("msg", "Go Go Go!"); 
return "go.jsp"; 


private Environment environment = null; 

QOverride 

public void setEnvironment (Environment environment) { 
this.environment=environment; 


} 


为 了 看 得 更 加 清楚 ， 显 示 设置 Servlet 定 义 时 的 contextConfigLocation 属 性 。 


<!--web.xml 一 -> 
<servlet> 
<servlet-name>let'sGo</servlet-name> 
<servlet-class>org.springframework.web.servlet .DispatcherServlet</servlet-class> 
<init-param> 
<param-name>contextConfigLocation</param-name> 
<param-value>WEB-INF/let'sGo-servlet .xml</param-value> 
</init-param> 
<load-on-startup>1</1lo0ad-on-startup> 
</servlet> 


然后 启动 调试 ， 并 且 打开 浏览 器 发 送 一 个 根 路 径 的 请 求 。 程 序 会 中 断 到 我 们 设置 的 断 点 的 地 方 。 这 时 将 鼠标 放 到 变量 上 就 可 以 看 到 其 内 容 了 ， 如 图 9-2 所 示 。 


可 以 看 到 propertySources 中 确实 包含 前 面 所 说 的 5 个 属性 ， 然 后 再 来 看 一 下 ServletConfig-PropertySource 的 内 部 结构 ， 如 图 9-3 所 示 。 


environment= StamdargdServletEnvironment (id=71) | 
男 BctiveProfiles= lLinkedHashSet<E» (id=81) 
男 defaultProfiles= LinkedHashSet<Es (lid=86) 
» dd logger= Jdkl4Logger (i:d=88) 
@ propertyResolver= PropertySourcesPropertyResolver (id=93) 
@ pro pertySources= Muta blePropertySources (lid=97) 
b logger= Jdkl4Logger (lid=88) 
4 四 propertySourceList= CopyOnWriteArrayList<E> (id=119) 


二 国 array= Qibject[s] (id=123) 
[0]= ServletConfigPropertySource (lid=128) 
[1]= ServletContextPropertySource (id=132) 
[2]= JndipropertySource (id=134) 
， [3]= MapPropertySource (id=13 
b 于 [二 = SystemEnvironmentpropertySource lid=138) 
b a lock= ReentrantLock (id=125) 


图 9-2 ”Environment 结 构 及 内 容 图 


4 加 propertySources= MutablePropertySources (id=97) 
PP i logger= Jdkl4Logger (id=88) 
4 日 propertySourcelist= CopyOnWriteArrayList<E> (id=119) 
4 加 array= Object[5] (id=123) 
4 各 [DO]= ServletConfigPropertySource (I:d=128) 
» 引 logger= Jdki4Logger (id=232) 
bp df name= "servletConfi igImitParams" (id=233) 
4 dd source= StandardWrapperFacade (id=234) 


5 四 config= StandardWrapper (id=237) 

> 男 context= ApplicationContextFacade (id=243) 
[1]= ServletContextPropertySource (id=132) 

[2]= JndiPropertySource (id=134) 

[3]= MapPropertySource (id=136) 

[4]= SystemEnvironmentPropertySource (i:d=138) 
ock= ReentrantLock (id=125) 


图 9-3 ”ServletConfigPropertySource 结 构图 


从 图 中 可 以 看 到 ServletConfigPropertySource 的 source 的 类 型 是 StandardWrapperFacade， 也 就 是 Tomcat 里 定义 的 ServletConfig 类 型 ， 所 以 ServletConfigPropertySource 封 装 的 就 是 
ServletConfig。 在 web.xml 中 定义 的 contextConfigLocation 可 以 在 config 下 的 parameters 里 看 到 ， 这 里 还 可 以 看 到 name 以 及 parent 等 属性 。 当 然 ， 这 里 的 config 是 私有 的 ， 不 可 以 直接 调用 ，config 其 


实 是 Tomcat 中 的 StandardWrapper 一 一 存放 Servlet 的 容器 (图 9-4) 。 


ServletContextPropertySource 中 保存 的 是 ServletContext (图 9-5) 。 


name= "let'sGo" (d=1367n) 

ninstances= 0 
notificationInfo= null 

oname= ObjectName (Id=1368) 

Overndable= false 


parametersLock= ReentrantReadWrteLock (Id=1371) 
pardnt= StandardContext (id=1372) 
parentClassLoader= null 

pipeline= StandardPipeline (id=1373) 


= 


山 
{contextCconfigLocation=WEB-INF/let'sGo-servlet. xml)} 


图 9-4 ”ServletConfigPropertySource 之 config 属 性 结构 


4 加 propertySources= MutablePropertySources (id=97) 
可 logger= Jdkl4Logger (id=88) 
a 罩 PropertySourcelList= CopyOnWriteArrayList<E> (id=119) 
4 国 array= Object[5] (1:d=123) 
b [0]= ServletConfigPropertySource (id=128) 
EE [1]= ServletContextPropertySource (id=132) 
ed logger= Jdkl4Logger (id=1410) 


dt name= "servletContextInitParams" (id=1411) 
对 source= ApplicationContextFacade (id=243) 


[2]= JndiPropertySource (ld=1 


[3]= MapPropertySource (id=136) 
[4]= SystemEnvironmentpropertySource (id=138) 
» lock= ReentrantLock (id=125) 


图 9-5 ServletContextPropertySource 


JndiPropertySource 从 名 字 就 很 容易 理解 ， 存 放 的 是 Jjndi， 由 于 这 里 没有 使 用 Jndi， 所 以 就 不 细 讲 了 。MapPropertySource 存 放 的 是 我 们 所 用 的 虚拟 机 的 属性 ， 如 Java 的 版 本 、 所 用 操作 系统 的 名 称 、 
操作 系统 的 版 本 号 、 用 户主 目录 、 临 时 目录 、Catalina (Tomcat) 的 目录 等 内 容 ; SystemEnvironmentPropertySource 存 放 的 是 环境 变量 ， 也 就 是 我 们 设置 的 AVA_HOME、Path 等 属性 。 


可 见 Environment 的 功能 非常 强大 。 通 过 慢 慢 体会 Environment， 我 们 就 可 以 对 程序 中 的 “环境 ”这 个 词 有 更 深入 的 理解 。 


看 完整 体 结构 ， 接 下 来 分 别 看 一 下 spring 中 三 个 类 的 具体 创建 过 程 。 


9.2 HttpServletBean 


通过 前 面 对 Servlet 的 分 析 ， 我 们 知道 Servlet 创 建 时 可 以 直接 调用 无 参数 的 init 方 法 。HttpServletBean 的 init 方 法 如 下 : 


// org.springframework.web.servlet .HttpServletBean 
public final void init() throws ServletException { 
if (logger.isDebugEnabled()) { 
logger.debug ("Initializing servlet '" + getServletName() + "™'"); 


try { 
// 将 Servlet 中 配置 的 参数 封装 到 pvs 变 量 中 ，requiredProperties 为 必需 参数 ， 如 果 没 配置 将 报 异 常 

PropertyValues pvs = new ServletConfigPropertyValues (getServletConfig () this.requiredProperties); 
BeanWrapper bw = PropertyAccessorFactory.forBeanPropertyAccess (this); 
ResourceLoader resourceLoader = new ServletContextResourceLoader (getServletContext ()); 
bw.registerCustomEditor (Resource.class, new esourceEditor (resourceLoader, getEnvironment () ) ) 7 
// 模 板 方法 ， 可 以 在 子 类 调用 ， 做 一 些 初始 化 工作 。bw 代 表 DispatcherServlet 
initBeanWrapper (bw) 7 
// 将 配置 的 初始 化 值 (如 contextConfigLocation) 设置 到 DispatcherServlet 
bw. setPropertyValues (pvs, true); 

}catch (BeansException ex) { 
logger.error ("Failed to set bean properties on servlet '" + getServletName() + "'", ex); 
throw ex; 


让 
// 模板 方法 ， 子 类 初始 化 的 入 口 方法 
initServletBean () 7 
if (logger.isDebugEnabled()) { 
logger.debug ("Servlet '" + getServletName () + "' configured successfully"); 
} 


可 以 看 到 ， 在 HttpServletBean 的 init 中 ， 首 先 将 Servlet 中 配置 的 参数 使 用 BeanWrapper 设 置 到 DispatcherServle 的 相关 属性 ， 然 后 调用 模板 方法 initServletBean， 子 类 就 通过 这 个 方法 初始 化 。 


BeanWrapper 是 什么 ,怎么 用 


BeanWrapper 是 Spring 提 供 的 一 个 用 来 操作 JavaBean 属 性 的 工具 ， 使 用 它 可 以 直接 修改 一 个 对 象 的 属性 ， 示 例如 下 : 


public class User { 
String userName; 
public String getUserName () { 
return userName; 


public void setUserName (String userName) { 
this.userName = userName; 


i 


} 
public class BeanWrapperTest { 
public static void main (String[] args) { 
User user = new User(); 
BeanWrapper bw = PropertyAccessorFactory.forBeanPropertyAccess (user); 


bw.setPropertyValue ("userName"，" 张 三 ") 了 

System.out .Println (user.getUserName () ) ; // 输 出 张 三 
PropertyValue value = new PropertyValue ("userName", " 李 四 "); 
bw.setPropertyValue (value); 

System.out .println (user.getUserName () ) ; // 输 出 李 四 


这 个 例子 首先 新 建 了 一 个 User 对 象 ， 其 次 使 用 PropertyAccessorFactory 封 装 成 Bean-Wrapper 对 象 ， 这 样 就 可 以 使 用 BeanWrapper 对 象 对 其 属性 userName 进 行 操 作 。Bean-Wrappet 的 使 用 就 是 这 么 简单 ， 理 解 了 
这 个 例子 ， 也 就 可 以 理解 HttpServletBean 中 设置 属性 的 方法 了 。 


9.3 FrameworkServlet 


从 HttpServletBean 中 可 知 ，FrameworkServlet 的 初始 化 入 口 方法 应 该 是 initServletBean， 其 代码 如 下 : 
// org.springframework.web.servlet .FrameworkServlet 
protected final void initServletBean() throws ServletException { 
getServletContext () .log ("Initializing Spring FrameworkServlet '" + getServletName() + "™'"); 
if (this.logger.isInfoPnabled()) { 
this.logger.info("FrameworkServlet '" + getServletName() + "': initialization started"); 
} 
long startTime = System.currentTimeMillis(); 
try { 
3» this.webApplicationContext = initWebApplicationContext (); 
initFrameworkServlet (); 
}catch (ServletException ex) { 
this.logger.error ("Context initialization failed", ex); 
throw ex; 
}catch (RuntimeException ex) { 
this.logger.error ("Context initialization failed", ex); 
throw ex; 
i 
if (this.logger.isInfoPnabled()) { 
long elapsedTime = System.currentTimeMillis () - startTime; 
this.logger.info("FrameworkServlet '" + getServletName() + "': initialization completed in "+ 


elapsedTime + " ms"); 


可 以 看 到 这 里 的 核心 代码 只 有 两 句 : 一 句 用 于 初始 化 WebApplicationContext， 另 一 句 用 于 初始 化 FrameworkServlet， 而 且 initFrameworkServlet 方 法 是 模板 方法 ， 子 类 可 以 覆盖 然后 在 里 面 做 一 些 
初始 化 的 工作 ， 但 子 类 并 没有 使 用 它 。 这 两 句 代码 如 下 : 


// org.springframework.web.servlet.FrameworkServlet.initServletBean 
this.webApplicationContext = initWebApplicationContext (); 
initFrameworkServlet (); 


可 见 FrameworkServlet 在 构建 的 过 程 中 的 主要 作用 就 是 初始 化 了 WebApplicationContext。 下 面 来 看 一 下 initWebApplicationContext 方 法 。 


// org.springframework.web.servlet .FrameworkServlet 
protected WebApplicationContext initWebApplicationContext() { 
// 获 取 rootContext 
WebApplicationContext rootContext = 
WebApplicationContextUtils.getWebApplicationContext (getServletContext ()); 
WebApplicationContext wac = null; 
// 如 果 已 经 通过 构造 方法 设置 了 webApplicationContext 
if (this.webApplicationContext != null) { 
wac = this.webApplicationContext; 
if (wac instanceof ConfigurableWebApplicationContext) { 


ConfigurableWebApplicationContext cwac = (ConfigurableWebApplicationContext) wac; 
if (!cwac.isaActive()) { 


if (cwac.getParent() == null) { 
cwac.setParent (rootContext); 


} 
configureAndRefreshWebApplicationContext (cwac); 


} 
} 


if (wac == null) { 
Jj¥ webAppl LoationContext 已 经 存在 ServletContext 中 时 ， 通 过 配置 在 Servlet 中 的 contextAttribute 和 参数 获取 
wac = findWebApplicationContext (); 

} 

if (wac == null) { 


// 如 果 webApplicationContext 还 没有 创建 ， 则 创建 一 个 
wac = createWebApplicationContext (rootContext); 


if (!this.refreshEventReceived) 


// 当 ContextRefreshedEvent 计件 没有 触发 时 调用 此 方法 ， 模 板 方法 ， 可 以 在 子 类 重 写 


onRefresh (wac); 


if (this.publishContext) { 
// 将 ApplicationContext 保 存 到 ServletContext 中 
String attrName = getServletContextAttributeName (); 
getServletContext () .setAttribute (attrName, wac); 
if (this.logger.isDebugEnabled()) { 
this.1logger.debug ("Published WebApplicationContext of servlet '"+ + getServletName () + 
"' as ServletContext attribute with name [" + attrName + "] 


} 
} 


return wac; 


initWebApplicationContext 方 法 做 了 三 件 事 : 


“ 获取 spring 的 根 容器 rootContext。 
' 设置 webApplicationContext 并 根据 情况 调用 onRefresh 方 法 。 


“ 将 webApplicationContext 设 置 到 ServletContext 中 。 


获取 spring 的 根 容器 rootContext 


获取 根 容器 的 原理 是 ， 默 认 情 况 下 spring 会 将 自己 的 容器 设置 成 ServletContext 的 


org.springframework.web.context.WebApplicationContext 中 。 


属性 ， 默 认 根 容器 的 key 为 org.springframework.web.context.WebApplicationContext.ROOT， 定 义 在 


String ROOT WEB APPLICATION CONTEXT ATTRIBUTE = WebApplicationContext.class.getName() + " .ROOT" 7 


所 以 获取 根 容器 只 需要 调用 ServletContext 的 getAttribute 就 可 以 了 。 


ServletContext#getAttribute ( “org.springframework.web.context .WebApplicationContext .ROOT” ) 


设置 webApplicationContext 并 根据 情况 调用 onRefresh 方 法 
设置 webApplicationContext 一 共有 三 种 方法 。 


第 一 种 方法 是 在 构造 方法 中 已 经 传递 webApplicationContext 参 数 ， 这 时 只 需要 对 其 进行 一 些 设置 即 可 。 这 种 方法 主要 用 于 Servlet3.0 以 后 的 环境 中 ，Servlet3.0 之 后 可 以 在 程序 中 使 


ServletContext.addServlet 方 式 注册 Servlet， 这 时 就 可 以 在 新 建 FrameworkServlet 和 其 子 类 的 时 候 通 过 构成 方法 传递 已 经 准备 好 的 webApplicationContext。 


第 二 种 方法 是 webApplicationContext 已 经 在 ServletContext 中 了 。 这 时 只 需要 在 配置 Servlet 的 时 候 将 ServletContext 中 的 webApplicationContext 的 name 配 置 到 contextAttribute 


比如 ， 在 ServletContext 中 有 一 个 叫 haha 的 webApplicationContext， 可 以 这 么 将 它 配置 到 Spring MVC 中 : 


属性 就 可 以 了 。 


<!--Web.xml --> 
<servlet> 
<servlet-name>let'sGo</servlet-name> 


<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> 
<init-param> 
<param-name>contextAttribute</param-name> 
<param-value>haha</param-value> 
</init-param> 
<load-on-startup>1</1l0ad-on-startup> 
</servlet> 


第 三 种 方法 是 在 前 面 两 种 方式 都 无 效 的 情况 下 自己 创建 一 个 。 正 常情 况 下 就 是 使 
configureAndRefreshWebApplicationContext 方 法 ， 代 码 如 下 : 


的 这 种 方式 。 创 建 过 程 在 createWebApplicationContext 方 法 中 ，createWebApplicationContext 内 部 又 调用 了 


// org.springframework.web.servlet.FrameworkServlet 


protected WebApplicationContext createWebApplicationContext (ApplicationContext parent) { 
/ /获取 创建 类 型 


Class<?> contextClass = getContextClass () 7 
if (this.logger.isDebugEnabled()) { 
this.logger.debug ("Servlet with name '" + getServletName() + 
"' will try to create custom WebApplicationContext context of class '" 
contextClass.getName() + "'" + ", using parent context [" + Parent + " 


E 

// 检 查 创建 类 型 
if (!ConfigurableWebApplicationContext.class.isAssignableFrom(contextClass)) { 

throw new ApplicationContextException( 

"Fatal initialization error in servlet with name '" + getServletName() + 

"'; custom WebApplicationContext class [" + contextClass.getName() + 

"] is not of type ConfigurableWebApplicationContext"); 

} 

// 具 体 创建 
ConfigurableWebApplicationContext wac = 


(ConfigurableWebApplicationContext) BeanUtils.instantiateClass (contextClass); 
wac.setEnvironment (getEnvironment ()); 
wac.setParent (parent); 
// 将 设置 的 contextConfigLocation 参 数 传 给 wac， 默 认 传 入 WEB-INFO/ [ServletName]-Servlet.xml 
wac.setConfigLocation (getContextConfigLocation()); 


configureAndRefreshWebApplicationContext (wac) 7 
return wac; 
} 
protected void configureAndRefreshWebApplicationContext (ConfigurableWebApplicationContext wac) { 
if (ObjectUtils.idqentityToString (wac) .equals (wac.getId())) { 
// The application context id is still set to its original default value 
// -> assign a more useful id based on available information 
if (this.contextId != null) { 
wac.setId(this.contextId); 
jelse { 
wac.setId (ConfigurableWebApplicationContext .APPLICATION CONTEXT ID PREFIX + 
ObjectUtils.getDisplayString (getServletContext () .getContextPath()) + "/" + getServletName ()); 
} 
wac.setServletContext (getServletContext () ) 
wac.setServletConfig (getServletConfig()); 
wac.setNamespace (getNamespace () ); 
// 添 加 监听 ContextRefreshedEvent 的 监听 器 
wac.addApplicationListener (new SourceFilteringListener (wac, new ContextRefreshListenezr () ) ) 
// The wac environment's #initPropertySources will be called in any case when the context 
// is refreshed; do it eagerly here to ensure servlet property sources are in Place for 
// use in any post-processing or initialization that occurs below prior to #refresh 
ConfigurableEnvironment env = wac.getEnvironment (); 
if (env instanceof ConfigurableWebEnvironment) { 
((ConfigurableWebEnvironment) env) .initPropertySources (getServletContext (), getServletConfig()); 
} 
postProcessWebApplicationContext (wac); 
applyInitializers (wac); 
wac.refresh (); 


这 里 首先 调用 getContextClass 方 法 获取 要 创建 的 类 型 ， 它 可 以 通过 contextClass 属 性 设置 到 Servlet 中 ， 默 认 使 用 org.springframework.web.context.support.Xml-WebApplication-Context。 然 后 
检查 属 不 属于 ConfigurableWebApplicationContext 类 型 ， 如 果 不 属于 就 殷 出 异常 。 接 下 来 通过 BeanUtils.instantiateClass (contextClass) 进行 创建 ， 创 建 后 将 设置 的 contextConfigLocation 传 入 ， 如 
果 没 有 设置 ， 默 认 传 入 WEB-INFO/[ServletName]-Servlet.xml， 然 后 进行 配置 。 其 他 内 容 基 本 上 都 很 容易 理解 ， 需 要 说 明 的 是 ， 在 configureAndRefreshWebApplicationContext 方 法 中 给 wac 添 加 了 监 
听 器 。 


wac.addApplicationListener (new SourceFilteringListener (wac, new ContextRefreshListener())); 


SourceFilteringListener 可 以 根据 输入 的 参数 进行 选择 ， 所 以 实际 监听 的 是 ContextRefresh-Listener 所 监听 的 事件 。ContextRefreshListener 是 FrameworkServlet 的 内 部 类 ， 监 听 Context- 
RefreshedEvent 事 件 ， 当 接收 到 消息 时 调用 FrameworkServlet 的 onApplicationEvent 方 法 ， 在 onApplicationEvent 中 会 调用 一 次 onRefresh 方 法 ， 并 将 refreshEventReceived 标 志 设 置 为 true， 表 示 已 经 
refresh 过 ， 代 码 如 下 : 


// org.springframework.web.servVlet.FrameworkSerVlet 
Private class ContextRefreshListener implements APP1icationListener<ContextRefreshedEvent> { 
QOverride 
Public void onApplicationEvent (ContextRefreshedEvent event) { 
FrameworkServlet.this.onApplicationEvent (event); 
} 
} 
Public void onApplicationEvent (ContextRefreshedEvent event) { 
this.refreshEeventReceived = true; 
onRefresh (event .getApplicationContext ()); 


再 回 到 initWebApplicationContext 方 法 ， 可 以 看 到 后 面 会 根据 refreshEventReceived 标 志 来 判断 是 否 要 运行 onRefresh。 


// org.springframework.web.servlet .FrameworkServlet .initWebApplicationContext 
if (!this.refreshEventReceived) { 
onRefresh (wac); 


} 


当 使 用 第 三 种 方法 初始 化 时 已 经 refresh ， 不 需要 再 调用 onRefresh。 同 样 在 第 一 种 方式 中 也 调用 了 configureAndRefreshWebApplicationContext 方 法 ， 也 refresh 过 ， 所 以 只 有 使 用 第 二 种 方式 初始 
化 webApplicationContext 的 时 候 才 会 在 这 里 调用 onRefresh 方 法 。 不 过 不 管用 哪 种 方式 调用 ，onRefresh 最 终 肯 定 会 而 且 只 会 调用 一 次 ， 而 且 DispatcherServlet 正 是 通过 重 写 这 个 模板 方法 来 实现 初始 化 
的 。 


将 webApplicationContext 设 置 到 ServletContext 中 


最 后 会 根据 publishContext 标 志 判 断 是 否 将 创建 出 来 的 webApplicationContext 设 置 到 ServletContext 的 属性 中 ，publishContext 标 志 可 以 在 配置 Servlet 时 通过 init-param 参 数 进行 设 
置 ，HttpServletBean 初 始 化 时 会 将 其 设置 到 publishContext 参 数 。 之 所 以 将 创建 出 来 的 webApplicationContext 设 置 到 ServletContext 的 属性 中 ， 主 要 是 为 了 方便 获取 ， 在 前 面 获取 
RootApplicationContext 的 时 候 已 经 介绍 过 。 


回 


前 面 介绍 了 配置 servlet 时 可 以 设置 的 一 些 初始 化 参数 ， 总 结 如 下 : 


所 


contextAtttibute: 在 ServletContext 的 属性 中 ， 要 用 作 WebApplicationContext 的 属性 名 称 。 
“ contextClass: 创建 WebApplicationContext 的 类 型 。 
contextConfigLocation: Spring MVC 配 置 文件 的 位 置 。 


“ publishContext: 是 否 将 webApplicationContext 设 置 到 ServletContext 的 属性 。 


9.4 DispatcherServlet 


onRefresh 方 法 是 DispatcherServlet 的 入 口 方法 。onRefresh 中 简单 地 调用 了 initStrategies， 在 initStrategies 中 调用 了 9 个 初始 化 方法 : 


// org.springframework.web.servlet .DispatcherServlet 

protected void onRefresh (ApplicationContext context) { 
initStrategies (context); 

} 

protected void initStrategies (ApplicationContext context) { 
initMultipartResolver (context); 
initLocaleResolver (context); 
initThemeResolver (context); 
initHandlerMappings (context); 
initHandlerAdapters (context); 
initHandlerExceptionResolvers (context); 
initRequestToViewNameTranslator (context); 
initViewResolvers (context); 


initFlashMapManager (context); 


因 


可 能 有 读者 不 理 来 刷新 容器 


的 ,initStrategies 


解 为 什么 要 这 么 写 ， 为 什么 不 将 initStrategies 的 具体 实现 直接 写 到 onRefresh 中 呢 ? initStrategies 方 法 不 是 多 余 的 吗 ? 其 实 这 主要 是 分 层 的 原因 ，onRefresh 是 
来 初始 化 一 些 策略 组 件 。 如 果 把 initStrategies 里 面 的 代码 直接 写 到 onRefresh 里 面 ， 对 于 程序 的 运行 也 没有 影响 ， 不 过 这 样 一 来 ， 如 果 在 onRefresh 中 想 再 添加 别 的 功能 ， 就 会 没有 将 
其 单独 写 一 个 方法 出 来 逻辑 清晰 ， 不 过 这 并 不 是 最 重要 的 ， 更 重要 的 是 ， 如 果 在 别 的 地 方 也 需要 调用 initStrategies 方 法 (如 需要 修改 一 些 策略 后 进行 热 部 署 ) ， 但 initStrategies 没 独立 出 来 ， 就 只 能 调 
onRefresh， 那 样 在 onRefresh 增 加 了 新 功能 的 时 候 就 麻烦 了 。 另 外 单独 将 initStrategies 写 出 来 还 可 以 被 子 类 覆盖 ， 使 用 新 的 模式 进行 初始 化 。 


日 


initstrategies 的 具体 内 容 非常 简单 ， 就 是 初始 化 的 9 个 组 件 ， 下 面 以 LocaleResolver 为 例 来 分 析 具 体 的 初始 化 方式 : 


// org.springframework.web.servlet .DispatcherServlet 
private void initLocaleResolver (ApplicationContext context) { 
try { 
// 在 context 中 获取 
this.localeResolver Context .getBean (LOCALE RESOLVER BEAN NAME, LocaleResolver.class); 
if (logger.isDebugEnabled()) { 
logger.debug ("Using LocaleResolver [" + this.localeResolver + "]"); 


}catch (NoSuchBeanDefinitionException ex) { 
// 使 用 默认 策略 
this.localeResolver getDefaultStrategy (context, LocaleResolver.class); 
if (logger.isDebugEnabled()) { 
logger.debug ("Unable to locate LocaleResolver with name '" + LOCALE RESOLVER BEAN NAME + 
"': using default [" + this.localeResolver + "]"); En 


初始 化 方式 分 两 步 : 首先 通过 context.getBean 在 容器 里 面 按 注册 时 的 名 称 或 类 型 (这 里 指 “localeResolver” 名 称 或 者 LocaleResolver.class 类 型 ) 进行 查找 ， 所 以 在 Spring MVC 的 配置 文件 中 只 : 
配置 相应 类 型 的 组 件 ， 容 器 就 可 以 自动 找到 。 如 果 找 不 到 就 调用 getDefaultStrategy 按 照 类 型 获取 默认 的 组 件 。 需 要 注意 的 是 ， 这 里 的 context 指 的 是 Frame-workServlet 中 创建 的 
WebApplicationContext， 而 不 是 ServletContext。 下 面 介绍 getDefault-Strategy 是 怎样 获取 默认 组 件 的 。 


要 


H 


// org.springframework.web.servlet .DispatcherServlet 
protected<T> T getDefaultStrategy (ApplicationContext context, Class<T> strategyInterface) { 
List<T> strategies = getDefaultStrategies (context, strategyInterface); 
if (strategies.size() != 1) { 
throw new BeanInitializationException( 
"DispatcherServlet needs exactly 1 strategy for interface [" + strategyInterface.getName() + "]"); 


} 
return strategies.get (0); 
} 
protected <T> List<T> getDefaultStrategies (ApplicationContext context, Class<T> StrategyInterface) { 
String key = strategyInterface.getName (); 
// 从 defaultStrategies 获 取 所 需 策 略 的 类 型 
String value = defaultStrategies.getProperty (key); 
if (value != null) { 
// 如 果 有 多 个 默认 值 ， 以 去 号 分 割 为 数组 
String[] classNames StringUtils.commaDelimitedListToStringArray (value); 
List<T> strategies = new ArrayList<T> (classNames.length); 
// 按 获取 到 的 类 型 初始 化 策略 
for (String className : 
try { 
Class<?> clazz = ClassUtils.forName (className, DispatcherServlet.class.getClassLoader()); 
Object strategy = createDefaultStrategy (context, clazz); 
strategies.add( (T) strategy); 
}catch (ClassNotFoundException ex) { 
throw new BeanInitializationException( 
"Could not find DispatcherServlet's default strategy class [" + className + 
"] for interface [" + key + "]", ex); 
}catch (LinkageError err) { 
throw new BeanInitializationException( 
"Error loading DispatcherServlet's default strategy class [" + className + 
"] for interface [" + key + "]: problem with class file or dependent class", err); 


classNames) { 


} 
} 
return strategies; 
J}else { 
return new LinkedList<T>(); 
} 


可 以 看 到 getDefaultStrategy 中 调用 了 getDefaultStrategies， 后 者 返回 的 是 List， 这 是 因 
了 getDefaultStrategies 方 法 ， 并 返回 返回 值 的 第 一 个 结果 。 


为 HandlerMapping 等 组 件 可 以 有 多 个 ， 所 以 定义 了 getDefaultStrategies 方 法 ，getDefaultStrategy 直 接 调 


的 是 看 className 怎 么 来 的 ， 找 到 了 className 的 来 源 ， 也 就 可 以 理解 默认 初始 化 的 方 
属性 ， 在 static 


getDefaultStrategies 中 实际 执行 创建 的 方法 是 ClassUtils.forName， 它 需要 的 参数 是 class-Name， 所 以 最 
式 。className 来 自 自 default-Strategies.getProperty (key) 。 所 以 关键 点 就 在 defaultStrategies 中 ，defaultStrategies 是 一 个 静态 
块 中 进行 初始 化 的 。 


classNames，classNames 又 来 自 value， 而 value 来 


// org.springframework.web.servlet .DispatcherServlet 
private static final Properties defaultSstrategies; 


static { 
try { 
ClassPathResource resource = new ClassPathResource (DEFAULT STRATEGIES PATH, DispatcherServlet.class); 
defaultStrategies = PropertiesLoaderUtils.loadProperties (resource); 
}catch (IOException ex) { 
throw new IllegalStateException ("Could not load 'DispatcherServlet.properties': " + ex.getMessage()); 


} 


我 们 看 到 defaultStrategies 是 DispatcherServlet 类 所 在 包 下 的 DEFAULT_STRATEGIES_PATH 文 件 里 定义 的 属性 ，DEFAULT_STRATEGIES_PATH 的 值 是 DispatcherServlet.properties。 所 以 
存放 的 是 org.springframework.web.DispatcherServlet.properties 里 面 定义 的 键 值 对 ， 代 码 如 下 : 


HI 


defaultStrategies 里 


# org.springframework.web.DispatcherServlet .properties 

# Default implementation classes for DispatcherServlet's strategy interfaces. 

# Used as fallback when no matching beans are found in the DispatcherServlet context. 
# Not meant to be customized by application developers. 这 些 配 置 是 固定 的 ， 开 发 者 不 可 以 定制 


org. 
org. 
org. 


org. 


org. 


Og 
org. 
org. 


springframework .web. 
springframework .web. 
springframework .web. 
org.springframework. 
springframework .web. 
org.springframework. 
org.springframework. 
springframework .web. 
org.springframework. 
org.springframework. 
springframework .web. 
springframework .web. 
springframework .web. 


servlet .LocaleResolver=org.springframework.web.servlet.il8n.AcceptHeaderLocaleResolver 

servlet .ThemeResolver=org.springframework .web.servlet.theme.FixedThemeResolver 

servlet .HandlerMapping=org.springframework .web.servlet.handler .BeanNameUrlHandlerMapping, \ 

web.servlet .mvc.annotation.DefaultAnnotationHandlerMapping 

servlet .HandlerAdapter=org.springframework .web.servlet .mvc.HttpRequestHandlerAdapter, \ 

web.servlet .mvc.SimpleControllerHandlerAdapter, \ 

web.servlet .mvc.annotation.AnnotationMethodHandlerAdapter 

servlet .HandlerExceptionResolver=org.springframework.web.servlet .mve.annotation.AnnotationMethodHandlerExceptionResolver, \ 
web.servlet .mvc.annotation.ResponseStatusExceptionResolver, \ 

web.servlet .mvc.support .DefaultHandlerExceptionResolver 

servlet .RequestToViewNameTranslator=org.springframework.web.servlet .view.DefaultRequestToViewNameTranslator 
servlet .ViewResolver=org.springframework.web.servlet .view.InternalResourceViewResolver 

servlet .FlashMapManager=org.springframework.web.servlet.support.SessionFlashMapManager 


可 以 看 到 ， 这 里 确实 定义 了 不 同 组 件 的 类 型 ， 一 共 定义 了 8 个 组 件 ， 处 理 上 传 组 件 Multi-partResolver 是 没有 默认 配置 的 ， 这 也 很 容 


易 理解 ， 并 不 是 每 个 应 


都 需要 上 传 功能 ， 即 使 需要 上 传 也 不 一 定 就 


使 用 MultipartResolver， 所 以 MultipartResolver 不 需要 默认 配置 。 另 外 HandlerMapping、HandlerAdapter 和 HandlerExceptionResolver 都 配置 了 多 个 ， 其 实 View-Resolver 也 可 以 有 多 个 ， 只 是 默认 
的 配置 只 有 一 个 。 


这 里 需要 注意 两 个 问题 : 首先 默认 配置 并 不 是 最 优 配置 ， 也 不 是 spring 的 推荐 配置 ， 只 是 在 没有 配置 的 时 候 可 以 有 个 默认 值 ， 不 至 于 空 着 。 里 面 的 有 些 默 认 配置 甚至 已 经 被 标注 为 @Deprecated， 表 示 
已 弃 用 ， 如 DefaultAnnotationHandlerMapping、Annotation-MethodHandler-Adapter 以 及 AnnotationMethodHandlerExceptionResolver。 另 外 需要 注意 的 一 点 是 ， 默 认 配 置 是 在 相应 类 型 没有 配 


的 时 候 才 会 使 用 ， 如 当 使 用 <mvcannotation-driven/> 后 ， 并 不 会 全 部 使 用 默认 配置 。 因 为 它 配置 了 HandlerMapping、HandlerAdapter 和 Handler-ExceptionResolver， 而 且 还 做 了 很 多 别 的 工作 ， 
更 详细 的 内 容 可 以 查看 org.springframework.web.servlet.config.AnnotationDrivenBeanDefinitionParser。 


Dispatcherservlet 的 创建 过 程 主要 是 对 9 大 组 件 进行 初始 化 ， 具 体 每 个 组 件 的 作用 后 面具 体 讲解 。 


在 spring 的 xml 文 件 中 通过 命名 空间 配置 的 标签 是 怎么 解析 的 


我 们 都 知道 ， 在 spring 的 xml 配 置 文件 中 可 以 使 用 很 多 命名 空间 来 配置 ， 命 名 空间 配置 的 内 容 具 体 是 怎么 解析 的 呢 ? 对 于 一 个 具体 的 命名 空间 ，spring 是 怎么 找到 解析 它 的 类 的 呢 ? 


其 实在 spring 中 是 把 解析 标签 的 类 都 放 到 了 相应 的 META-INF 目 录 下 的 springhandlers 文 件 中 ， 然 后 从 那里 面 找 ， 比 如 ，mvc 命 名 空间 的 解析 设置 在 spring-webmvc-4.1.5.RELEASE.jar 包 下 META- 
INF/spring.handlers 文 件 中 ， 其 内 容 为 


http\://www.springframework.org/schema/mvc=org.springframework.web.servlet .config.MvcNamespaceHandler 


这 也 就 告诉 我 们 ， 处 理 mvc 这 个 命名 空间 的 配置 要 使 用 MvcNamespaceHandler (在 其 内 部 将 mvc:annotation-driven 的 解析 交 给 AnnotationDrivenBeanDefinitionPatrser) 。 


解析 配置 的 接口 是 org.springframewotk.beans.factory.xml.NamespaceHandler， 它 的 继承 结构 如 下 (NamespaceHandlerSupport 的 子 类 有 很 多 ， 图 9-6 只 给 出 了 MvcName-spaceHandler) 。 


I NamespaceHandler 


CNamespaceHandlerSupport 


CSimpleConstructorNamespaceHndle 


MvcNamespaceHandle 


图 9-6 ”NamespaceHandler 继 承 结构 图 


NamespaceHandler 里 一 共 定义 了 三 个 方法 : init、parse 和 decorate。init 是 用 来 初始 化 自己 的 ; parse 用 于 将 配置 的 标签 转换 成 spring 所 需要 的 BeanDefinition; decorate 是 装饰 的 意思 ，decorate 方 法 的 作用 是 对 所 
在 的 BeanDefinition 进 行 一 些 修改 ， 用 得 比较 少 。 


//org.springframework.beans.factory.xml .NamespaceHandler 
public interface NamespaceHandler { 
void init(); 
BeanDefinition parse (Element element, ParserContext parserContext); 
BeanDefinitionHolder decorate (Node source, BeanDefinitionHolder definition, ParserContext parserContext); 


NamespaceHandler 的 实现 类 主要 有 三 个 : NamespaceHandlerSupport、SimpleConstructorNamespaceHandler、SimplePropertyNamespaceHandler。 其 中 NamespaceHandler-Support 是 NamespaceHandlet 的 默认 实现 ， 
一 般 的 NamespaceHandler 都 继承 自 这 个 类 (当然 也 有 特殊 情况 ，springSecutity 的 SecurityNamespaceHandlet 是 直接 实现 的 NamespaceHandler 接 口 ) ，SimpleConstructorNamespaceHandler 用 于 统一 对 通过 c: 配 置 的 构 
造 方法 进行 解析 ，SimplePropertyNamespaceHandletr 用 于 统一 对 通过 p: 配 置 的 参数 进行 解析 。 


NamespaceHandlerSupport 并 没有 做 具体 的 解析 工作 ， 而 是 定义 了 三 个 处 理 器 parsers、decorators、attributeDecorators， 分 别 用 于 处 理解 析 工 作 、 处 理 标 签 类 型 、 处 理 属性 类 型 的 装饰 。 接 口 的 parse 和 decorate 
方法 的 执行 方式 是 先 找到 相应 的 处 理 器 ， 然 后 进行 处 理 。 具 体 的 处 理 器 由 子 类 实现 ， 然 后 注册 到 NamespaceHandlerSupport 上 面 。 所 以 要 定义 一 个 命名 空间 的 解析 器 ， 只 需要 在 init 中 定义 相应 的 parsers、 
decorators、attributeDecorators 并 注册 到 NamespaceHandlerSupport 上 面 。 下 面 是 NamespaceHandler-Support 的 代码 以 及 解析 mvc 命 名 空间 的 MvcNamespaceHandlet 的 代码 : 


package org.springframework.beans.factory.xml; 
// 省 略 了 imports 
public abstract class NamespaceHandlerSupport implements NamespaceHandler { 
private final Map<String, BeanDefinitionParser> parsers = 
new HashMap<String, BeanDefinitionParser>(); 
private final Map<String, BeanDefinitionDecorator> decorators = 
new HashMap<String, BeanDefinitionDecorator>(); 
Private final Map<String, BeanDefinitionDecorator> attributeDecorators = 
new HashMap<String, BeanDefinitionDecorator>(); 
QOverride 
public BeanDefinition parse (Element element, ParserContext parserContext) { 
return findParserForElement (element, parserContext) .parse (element, parserContext); 
} 


Private BeanDefinitionParser findParserForElement (Element element, ParserContext parserContext) { 
String localName = parserContext .getDelegate() .getLocalName (element); 
BeanDefinitionParser parser = this.parsers.get (localName); 


if (parser == null) { 
ParserContext .getReaderContext () .fatal ( 
"Cannot locate BeanDefinitionParser for element [" + localName + "]", element); 


} 


return parser; 


QOverride 
public BeanDefinitionHolder decorate( 
Node node, BeanDefinitionHolder definition, ParserContext parserContext) { 
return findDecoratorForNode (node, parserContext) .decorate (node, definition, parserContext); 
} 
Private BeanDefinitionDecorator findDecoratorForNode (Node node, ParserContext parserContext) { 
BeanDefinitionDecorator decorator = null; 
String localName = parserContext .getDelegate() .getLocalName (node); 
// 先 判断 是 标签 还 是 属性 ， 然 后 再 调用 相应 方法 进行 处 理 
if (node instanceof Element) { 
decorator = this.decorators.get (localName); 
}else if (node instanceof Attr) { 
decorator = this.attributeDecorators.get (localName); 
}else { 
parserContext .getReaderContext () .fatal ( 


"Cannot decorate based on Nodes of type [" + node.getClass () .getName () + "]", node); 
if (decorator == null) { 
ParserContext .getReaderContext () .fatal ("Cannot locate BeanDefinitionDecorator for "+ 
(node instanceof Element ? "element" : "attribute") + " [" + localName + "]", node); 


} 


return decorator; 


protected final void registerBeanDefinitionParser (String elementName, BeanDefinitionParser parser) { 
this.parsers.put (elementName, parser); 


protected final void registerBeanDefinitionDecorator (String elementName, BeanDefinitionDecorator dec) { 
this.decorators.put (elementName, dec); 
} 
protected final void registerBeanDefinitionDecoratorForAttribute (String attrName, BeanDefinitionDecorator dec) { 
this.attributeDecorators.put (attrName, dec); 
} 
} 
Package org.springframework.web.servlet.config; 
// 省 略 了 imports 
public class MvcNamespaceHandler extends NamespaceHandlerSupport { 
QOverride 
public void init() { 
registerBeanDefinitionParser 
registerBeanDefinitionParser 
registerBeanDefinitionParser 
registerBeanDefinitionParser 
registerBeanDefinitionParser 
registerBeanDefinitionParser 
registerBeanDefinitionParser 
registerBeanDefinitionParser 
registerBeanDefinitionParser 
registerBeanDefinitionParser 
registerBeanDefinitionParser 
registerBeanDefinitionParser 


"annotation-driven", new AnnotationDrivenBeanDefinitionParser()); 
"default-servlet-handler", new DefaultServletHandlerBeanDefinitionParser ()); 
"interceptors", new InterceptorsBeanDefinitionParser ()); 

"resources", new ResourcesBeanDefinitionParser ()); 

"view-controller", new ViewControllerBeanDefinitionParser()); 
"redirect-view-controller", new ViewControllerBeanDefinitionParser ()); 
"status-controller", new ViewControllerBeanDefinitionParser()); 
"view-resolvers", new ViewResolversBeanDefinitionParser()); 
"tiles-configurer", new TilesConfigurerBeanDefinitionParser()); 
"freemarker-configurer", new FreeMarkerConfigurerBeanDefinitionParser()); 
"velocity-configurer", new VelocityConfigurerBeanDefinitionParser () ) 7 
"groovy-configurer", new GroovyMarkupConfigurerBeanDefinitionParser()); 


从 这 里 就 可 以 看 到 mvc 命 名 空间 使 用 到 的 所 有 解析 器 ， 其 中 解析 “annotation-driven” 的 是 AnnotationDrivenBeanDefinitionParser。 


95 处 结 


本 章 主 要 分 析 了 Spring MVC 自 身 的 创建 过 程 ，Spring MVC 中 Servlet 一 共有 三 个 层次 ， 分 别 是 HttpServletBean、Frameworkservlet 和 DispatcherServlet。HttpServletBean 直 接 继 承 自 Java 的 
作用 是 将 Servlet 中 配置 的 参数 设置 到 相应 的 属性 ; FrameworkServlet 初 始 化 了 WebApplicationContext，DispatcherServlet 初 始 化 了 自身 的 9 个 组 件 。 


HttpServlet, 


FrameworkServlet 初 始 化 WebApplicationContext 一 共有 三 种 方式 ， 过 程 中 使 用 了 Servlet 中 配置 的 一 些 参 数 。 


整体 结构 非常 简单 一 一 分 三 个 层次 做 了 三 件 事 ， 但 具体 实现 过 程 还 是 有 点 复杂 的 。 这 其 实 也 是 spring 的 特点 : 结构 简单 ， 实 现 复杂 。 结 构 简单 主要 是 顶层 设计 好 ， 实 现 复杂 的 主要 是 提供 的 功能 比较 
多 ， 可 配置 的 地 方 也 非常 多 。 当 然 ， 正 是 因为 实现 复杂 ， 才 让 Spring MVC 使 用 起 来 更 加 灵活 ， 这 一 点 在 后 面 会 有 更 深刻 的 体会 。 如 果 能 静 下 心 来 对 照 着 源 代码 耐心 地 去 看 ， 还 是 很 容易 理解 的 。 


第 10 章 Spring MVC 之 用 


前 面 分 析 了 Spring MVC 的 创建 过 程 ， 本 章 分 析 Spring MVC 是 怎么 处 理 请 求 的 。 我 们 这 里 分 两 步 : 首先 分 析 HttpServletBean、FrameworkServlet 和 DispatcherServlet 这 三 个 Servlet 的 处 理 过程 ， 这 
样 大 家 可 以 明白 从 Servlet 容 器 将 请 求 交 给 Spring MVC 一 直到 DispatcherServlet 具 体 处 理 请 求 之 前 都 做 了 些 什么 ， 最 后 再 重点 分 析 Spring MVC 中 最 核心 的 处 理 方法 doDispatch 的 结构 。 


局 | 


10.1 HttpServletBean 


HttpServletBean 主 要 参与 了 创建 工作 ， 并 没有 涉及 请 求 的 处 理 。 之 所 以 单独 将 它 列 出 来 是 为 了 明确 地 告诉 大 家 这 里 没有 具体 处 理 请 求 。 


10.2 FrameworkServlet 


前 面 讲 过 Servlet 的 处 理 过 程 : 首先 是 从 Servlet 接 口 的 service 方 法 开始 ， 然 后 在 Http-Servlet 的 service 方 法 中 根据 请 求 的 类 型 不 同 将 请 求 路 由 到 了 doGet、doHead、doPost、doPut、doDelete、 
doOptions 和 doTrace 七 个 方法 ， 并 且 做 了 doHead、doOptions 和 doTrace 的 默认 实现 ， 其 中 doHead 调 用 doGet， 然 后 返回 只 有 header 没 有 body 的 response。 


三 | 


在 FrameworkServlet 中 重 写 了 service、doGet、doPost、doPut、doDelete、doOptions、doTrace 方 法 (除了 doHead 的 所 有 处 理 请 求 的 方法 ) 。 在 service 方 法 中 增加 了 对 PATCH 类 型 请 求 的 处 
理 ， 其 他 类 型 的 请 求 直 接 交 给 了 父 类 进行 处 理 ; doOptions 和 doTrace 方 法 可 以 通过 设置 dispatchOptionsRequest 和 dispatchTraceRequest 参 数 决定 是 自己 处 理 还 是 交 给 父 类 处 理 (默认 都 是 交 给 父 类 处 
理 ，doOptions 会 在 父 类 的 处 理 结果 中 增加 PATCH 类 型 ) ; doGet、doPost、doPut 和 dopDelete 都 是 自己 处 理 。 所 有 需要 自己 处 理 的 请 求 都 交 给 了 processRequest 方 法 进行 统一 处 理 。 


下 面 来 看 一 下 service 和 doGet 的 代码 ， 别 的 需要 自己 处 理 的 方法 都 和 doGet 类 似 。 


// org.springframework.web.servlet .FrameworkServlet 
protected void service (HttpServletRequest request, HttpServletResponse response) 
throws ServletException, IOException { 
String method = request .getMethod(); 
if (method.equalsIgnoreCase (RequestMethod.PATCH.name())) { 
processRequest (request, response); 
}else { 
super.service (request, response); 
} 
} 
protected final void doGet (HttpServletRequest request, HttpServletResponse response) 
throws ServletException, IOException { 
processRequest (request, response); 


我 们 发 现 这 里 所 做 的 事情 跟 HttpServlet 里 将 不 同类 型 的 请 求 路 由 到 不 同方 法 进行 处 理 的 思路 正好 相反 ， 这 里 又 将 所 有 的 请 求 合 并 到 了 processRequest 方 法 。 当 然 并 不 是 说 Spring MVC 中 就 不 对 
request 的 类 型 进行 分 类 ， 而 全 部 执行 相同 的 操作 了 ， 恰 恰 相 反 ，Spring MVC 中 对 不 同类 型 请 求 的 支持 非常 好 ， 不 过 它 是 通过 另外 一 种 方式 进行 处 理 的， 它 将 不 同类 型 的 请 求 用 不 同 的 Handler 进 行 处 理 ， 
后 面 再 详细 分 析 。 


可 全 
处 理 不 是 更 简单 吗 ? 从 现在 的 结构 来 看 确实 如 此 ， 不 过 那么 做 其 实 存在 着 一 些 问 题 。 比 如 ， 我 们 为 了 某 种 特殊 需求 需要 在 Post 请 求 处 理 前 对 request 做 一 些 处 理 ， 这 时 可 能 会 新 建 一 个 继承 


8 有 的 读者 会 想 ， 直 


接 覆 盖 了 service 不 是 就 可 以 了 吗 ? HttpServlet 是 在 service 方 法 中 将 请 求 路 由 到 不 同 的 方法 的 ， 如 果 在 service 中 不 再 调用 super.service()， 而 是 直接 将 请 求 交 给 processRequest 


Dispatcherservlet 的 类 ， 然 后 覆盖 doPost 方 法 ， 在 里 面 先 对 request 做 处 理 ， 然 后 再 调用 supper.doPost()， 但 是 父 类 根本 就 没 调用 doPost， 所 以 这 时 候 就 会 出 问题 了 。 虽 然 这 个 问题 的 解决 方法 也 很 简 


由 


下 面 就 来 看 processRequest 方 法 ，processRequest 是 FrameworkServlet 类 在 处 理 请 求 中 最 核心 的 方法 。 


// org.springframework.web.servlet .FrameworkServlet 
protected final void processRequest (HttpServletRequest request, HttpServletResponse response) 


throws ServletException, IOException { 
long startTime = System.currentTimeMillis(); 
Throwable failureCause = null; 
// 获取 LocaleContextHolder 中 原来 保存 的 LocaleContext 
LocaleContext previousLocaleContext = LocaleContextHolder.getLocaleContext (); 
// 获取 当前 请 求 的 LocaleContext 
LocaleContext localeContext = buildLocaleContext (request); 
// 获取 RequestContextHolder 中 原来 保存 的 RequestAttributes 
RequestAttributes previousAttributes = RequestContextHolder.getRequestAttributes (); 
// 获 取 当 前 请 求 的 ServletRequestAttributes 
ServletRequestAttributes requestAttributes = buildRequestAttributes (request, response, previousAttributes); 
WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager (request); 
asyncManager .registerCallableInterceptor (FrameworkServlet .class.getName (), new RequestBindingInterceptor()); 
// 将 当前 请 求 的 LocaleContext 和 ServletRequestAttributes 设 置 到 LocaleContextHolder 和 RequestContextHolder 
initContextHolders (request, localeContext, requestAttributes); 
try { 
// 实 际 处 理 请 求 入 口 
doService (request, response); 
}catch (ServletException ex) { 
failureCause = ex; 
throw ex; 
}catch (IOException ex) { 
failureCause = ex; 
throw ex; 
}catch (Throwable ex) { 
failureCause = ex; 
throw new NestedServletException ("Request Processing failed", ex); 
}finally { 
// 恢 复原 来 的 LocaleContext 和 ServletRequestAttributes 到 LocaleContextHolder 和 RequestContextHolder 中 
resetContextHolders (request, previousLocaleContext, previousAttributes); 
if (requestAttributes != null) { 
requestAttributes.requestCompleted(); 


} 

// 省 略 了 1og 代 码 

// 发 布 ServletRequestHandledEvent 消 息 

publishRequestHandledEvent (request, response, startTime, failureCause); 


和 a， 但 是 按 正常 的 逻辑 ， 调 用 doPost 应 该 可 以 完成 才 合 理 ， 而 且 一 般 情况 下 开发 者 并 不 需要 对 Spring MVC 内 部 的 结构 非常 了 解 ， 所 以 Spring MVC 的 这 种 做 法 虽然 看 起 来 有 点 笨拙 但 是 是 必要 的 。 


processRequest 方 法 中 的 核心 语句 是 doService (request，response) ， 这 是 一 个 模板 方法 ， 在 DispatcherServlet 中 具体 实现 。 在 doService 前 后 还 做 了 一 些 事 情 (也 就 是 大 家 熟悉 的 装饰 模式 ) : 首 


先 获取 了 LocaleContextHolder 和 RequestContextHolder 中 原来 保存 的 LocaleContext 和 RequestAttributes 并 设置 到 previousLocaleContext 和 previousAttributes 临 时 属性 ， 然 后 调 
buildLocaleContext 和 buildRequestAttributes 方 法 获取 到 当前 请 求 的 LocaleContext 和 RequestAttributes， 并 通过 initCon 


textHolders 方 法 将 它们 设置 到 LocaleContextHolder 和 Request- 


ContextHolder 中 (处理 完 请 求 后 再 恢复 到 原来 的 值 ) ， 接 着 使 用 request 拿 到 异步 处 理 管 理 器 并 设置 了 拦截 器 ， 做 完 这 些 后 执行 了 doService 方 法 ,执行 完 后 ， 最 后 (finally 中 ) 通过 resetContextHolders 


方法 将 原来 的 previousLocaleContext 和 previousAttributes 恢 复 到 Locale-ContextHolder 和 RequestContextHolder 中 ， 并 调 
ServletRequestHandledEvent 类 型 的 消息 。 


这 里 涉及 了 异步 请 求 相 关 的 内 容 ，Spring MVC 中 异步 请 求 的 内 容 会 在 后 面 专门 讲解 。 除 了 异步 请 求 和 调用 doService 方 法 具体 处 理 请 求 ，processRequest 自 己 


publishRequestHandledEvent 方 法 发 布 了 一 个 


和 RequestAttributes 的 设置 及 恢复 ; @ 处 理 完 后 发 布 了 Servlet-RequestHandledEvent 消 息 。 


要 做 了 两 件 事情 : @ 对 LocaleContext 


首先 来 看 一 下 LocaleContext 和 RequestAttributes。LocaleContext 里 面 存放 着 Locale (也 就 是 本 地 化 信息 ， 如 zh-cn 等 ) ，RequestAttributes 是 spring 的 一 个 接口 ， 通 过 它 可 以 
get/set/removeAttribute， 根 据 scope 参 数 判断 操作 request 还 是 session。 这 里 具体 使 用 的 是 ServletRe-questAttributes 类 ， 在 ServletRequestAttributes 里 面 还 封装 了 request、response 和 session， 而 


且 都 提供 


了 get 方 法 ， 可 以 直接 获取 。 下 面 来 看 一 下 ServletRequestAttributes 里 setAttribute 的 代码 (get/remove 都 大 同 小 异 ) 。 


// org.springframework.web.context.request.ServletRequestAttributes 
Public void setAttribute (String name, Object value, int scope) { 


if (scope 一 SCOPE REQUEST) { 
if (!isRequestActive()) { 
throw new IllegalStateException( 
"Cannot set request attribute - request is not active anymore!"); 
} 
this.request.setAttribute (name, value); 
}else { 
HttpSession session = getSession (true); 
this.sessionAttributesToUpdate.remove (name); 
session.setAttribute (name, value); 


设置 属性 时 可 以 通过 scope 判 断 是 对 request 还 是 session 进 行 设置 ， 具 体 的 设置 方法 非常 简单 ， 就 是 直接 对 request 和 session 操 作 ，sessionAttributesToUpdate 属 性 后 面 讲 到 Session- 
AttributesHandler 的 时 候 再 介绍 ， 这 里 可 以 先 不 考虑 它 。 需 要 注意 的 是 jsRequestActive 方 法 ， 当 调用 了 ServletRequestAttributes 的 requestCompleted 方 法 后 requestActive 就 会 变 为 false， 执 行 之 前 是 


true。 这 个 很 容易 理解 ，request 执 行 完了 ， 当 然 也 就 不 能 再 对 它 进 行 操作 了 ! 你 可 能 已 经 注意 到 ， 在 网 


现在 大 家 对 LocaleContext 和 RequestAttributes 已 经 有 了 大 概 的 了 解 ， 前 者 可 以 获取 Locale， 后 者 用 于 管理 request 和 session 的 


。 不 要 着 急 ， 我 们 接 下 来 看 LocaleContextHolder 和 Request-ContextHolder， 把 这 两 个 理解 了 也 就 全 部 明白 了 ! 


先 来 看 LocaleContextHolder， 这 是 一 个 abstract 类 ， 不 过 里 面 的 方法 都 是 static 的 ， 可 以 直接 调用 ， 而 且 没有 父 类 也 没有 子 类 ! 
abstract 的 使 用 方式 也 值得 我 们 学 习 。 在 LocaleContextHolder 中 定义 了 两 个 static 的 属性 。 


才 的 finally 块 中 已 调用 requestAttributes 的 requestCompleted 方 法 。 


属性 。 不 过 可 能 还 是 有 种 没有 理解 透 的 感觉 ， 因 为 还 不 知道 它 到 底 怎 么 


也 就 是 说 我 们 不 能 对 它 实例 化 ， 只 能 调用 其 定义 的 static 方 法 。 这 种 


// org.springframework.context.il8n.LocaleContextHolder 
private static final ThreadLocal<LocaleContext> localeContextHolder = 


new NamedThreadLocal<LocaleContext> ("Locale context"); 


private static final ThreadLocal<LocaleContext> inheritableLocaleContextHolder = 


这 


new NamedInheritableThreadLocal<LocaleContext> ("Locale context"); 


多 知道 点 


ThreadLocal 的 作用 及 其 实现 原理 


两 个 属性 都 是 ThreadLocal<LocaleContext> 类 型 的 ，LocaleContext 前 面 已 经 介绍 了 ，ThreadLocal 大 家 应 该 也 不 陌生 ， 很 多 地 方 都 用 了 它 。 


简单 来 说 ，ThreadLocal 类 型 的 属性 就 是 每 个 线程 都 可 以 独立 保存 自己 的 内 容 ， 虽 然 是 同一 个 属性 ， 但 不 同 的 线程 用 的 却 是 自己 独 有 的 一 份 。 


ThreadLocal 内 部 具体 的 实现 是 这 样 的 ， 首 先 在 Thread 内 部 封装 了 一 个 map 用 于 保存 一 些 值 ， 然 后 ThreadLocal 在 get/set 的 时 候 ， 首 先 拿 到 线程 自身 的 那个 map， 然 后 将 自己 作为 key， 所 要 保存 的 值 作为 
value，put 进 去 ， 这 样 就 将 具体 的 值 保存 在 了 每 个 线程 自身 上 面 ( 而 不 是 ThreadLocal 里 面 ) ， 所 以 每 个 线程 之 间 都 会 有 独立 的 一 份 ， 而 不 会 相互 影响 。 至 于 为 什么 要 用 map 而 不 是 Object， 也 很 容易 理解 ， 因 为 
这 样 每 个 线程 都 可 以 保存 不 止 一 个 ThreadLocal 类 型 的 属性 。 比 如 ， 在 LocaleContextHolder 里 面 有 两 个 ThreadLocal: locale-ContextHolder 和 inheritableLocaleContextHolder， 这 时 就 需要 实例 化 两 个 ThreadLocal， 然 
后 分 别 作为 key 保 存 到 Thread 里 面 ， 如 果 别 的 地 方 还 有 使 用 到 ThreadLocal 的 地 方 ， 再 实例 化 一 个 ThreadLocdl， 然 后 将 自己 作为 key，put 到 Thread 里 面 。 也 就 是 Thread 中 的 那个 map 的 每 一 个 key-value 代 表 着 一 个 


ThreadLocal 类 型 的 参数 。 这 个 map 属 性 叫 threadLocals， 它 的 类 型 是 定义 在 ThreadLocal 中 的 静态 类 ThreadLocal.ThreadLocalMap。 


LocaleContextHolder 类 里 面 封 装 了 两 个 


属性 localeContextHolder 和 inheritableLocale-ContextHolder， 它 们 都 是 LocaleContext， 其 中 第 二 个 可 以 被 子 线程 继承 。Locale-ContextHolder 还 提供 了 


get/set 方 法 ， 可 以 获取 和 设置 LocaleContext， 另 外 还 提供 了 get/setLocale 方 法 ， 可 以 直接 操作 Locale， 当 然 都 是 static 的 。 这 个 使 用 起 来 非常 方便 ! 比如 ， 在 程序 中 需要 用 到 Locale 到 时 候 ， 首 先 想到 的 


可 能 是 request.getLocale()， 这 是 最 直接 的 方法 。 不 过 有 时 候 在 service 层 需要 用 到 Locale 的 时 候 ， 再 用 这 种 方法 就 不 方便 了 ， 因 为 正常 来 说 service 层 是 没有 request 的 ， 这 时 可 能 就 需要 在 controller 层 将 


Locale 拿 出 来 ， 然 后 再 传 进去 了 ! 当然 这 也 没什么 ， 传 一 下 就 好 了 ， 但 最 重要 的 是 怎么 传 呢 ? 服务 层 的 代码 可 能 已 经 通过 测试 了 ， 如 果 想 将 Locale 传 进去 可 能 就 需要 改 接口 ， 而 修改 接口 可 能 会 引起 很 多 问 
题 ! 而 有 了 LocaleContextHolder 就 方便 多 了 ， 只 需要 在 server 层 直接 调用 一 下 LocaleContextHolder.getLocale() 就 可 以 了 ， 它 是 静态 方法 ， 可 以 直接 调用 ! 当然 ， 在 Spring MVC 中 Locale 的 值 并 不 总 是 
request.getLocale() 获 取 到 的 值 ， 而 是 采用 了 非常 灵活 的 机 制 ， 在 后 面 的 LocaleResolver 中 再 详细 讲解 。 


RequestContextHolder 也 是 一 样 的 道理 ， 里 面 封 装 了 RequestAttributes， 可 以 get/set/removeAttribute， 而 且 因 为 实际 封装 的 是 ServletRequestAttributes， 所 以 还 可 以 getRequest、 


getResponse、getSession! 这 样 就 可 以 在 任何 地 方 都 能 方便 地 获取 这 些 对 象 了 ! 另外 ， 因 为 里 面 封装 的 其 实 是 对 象 的 引用 ， 所 以 即使 在 doService 方 法 里 面 设置 的 Attribute， 使 / 
RequestContextHolder 也 一 样 可 以 获取 到 。 


加 


在 方法 最 后 的 finally 中 调用 resetContextHolders 方 法 将 原来 的 LocaleContext 和 Request-Attributes 又 恢复 了 。 这 是 | 
Handlerlnterceptor 是 在 doservice 内 部 的 ) 等 ， 为 了 不 影响 那些 操作 ， 所 以 需要 进行 恢复 。 


为 在 Sevlet 外 面 可 能 还 有 别 的 操作 ， 如 Filter (Spring-MVC 自 己 的 


最 后 就 是 publishRequestHandledEvent (request，response，startTime，failureCause) 发 布 消息 了 。 在 publishRequestHandledEvent 内 部 发 布 了 一 个 ServletRequestHandledEvent 消 息 ， 代 码 
如 下 : 


// org.springframework.web.serVlet.FrameworkSerVlet 
private void publishRequestHandledEvent ( 
HttpServletRequest request, HttpServletResponse response, long startTime, Throwable failureCause) { 
// publishEvents 可 以 在 配置 Servlet 时 设置 ， 默认 为 true 
if (this.publishEvents) { 
// 无 论 请 求 是 否 执行 成 功 都 会 发 布 消息 
long processingTime = System.currentTimeMillis() - startTime; 
int statusCode = (responseGetStatusAvailable ? response.getStatus() : -1); 
this.webApplicationContext .publishEvent ( 
new ServletRequestHandledEvent (this, 
request .getRequestURI (), request .getRemoteAddr(), 
request .getMethod(), getServletConfig() .getServletName (), 
WebUtils.getSessionId (request), getUsernameForRequest (request), 
processingTime, failureCause, statusCode)); 


当 publishEvents 设 置 为 true 时 ， 请 求 处 理 结束 后 就 会 发 出 这 个 消息 ， 无 论 请 求 处 理 成 功 与 否 都 会 发 布 。publishEvents 可 以 在 web.xml 文 件 中 配置 Spring MVC 的 Servlet 时 配置 ， 默 认为 true。 我 们 可 
以 通过 监听 这 个 事件 来 做 一 些 事情 ， 如 记录 日 志 。 


下 面 就 写 一 个 记录 日 志 的 监听 器 。 


@Component 


public class ServletRequestHandledEventListener implements ApplicationListener<ServletRequestHandledEvent> { 


final static Logger logger = LoggerFactory.getLogger ("RequestProcessLog"); 
QOverride 


public void onApplicationEvent (ServletRequestHandledEvent event) { 
logger.info (event .getDescription()); 
} 


我 们 可 以 看 到 ， 只 要 简单 地 继承 ApplicationListener， 并 且 把 自己 要 做 的 事情 写 到 onApplicationEvent 量 
类 上 面 标注 @Component 就 可 以 了 。 


他 


且 面 就 行 了 。 很 简单 吧 ! 当然 要 把 它 注册 到 spring 容 器 里 才能 起 作用 ， 如 果 开 启 了 注释 ， 只 要 在 


到 现在 为 止 FrameworkServlet 就 分 析 完了 ， 我 们 再 简单 地 回顾 一 下 : 首先 是 在 service 方 法 里 添加 了 对 PATCH 的 处 理 ， 并 将 所 有 需要 自己 处 理 的 请 求 都 集中 到 了 processRequest 方 法 进行 统一 处 理 ， 这 
和 HttpServlet 里 面 根据 request 的 类 型 将 请 求 分 配 到 各 个 不 同 的 方法 进行 处 理 的 过 程 正好 相反 。 


然后 就 是 processRequest 方 法 ， 在 processRequest 里 面 


要 的 处 理 逻 辑 交 给 了 doservice， 这 是 一 个 模板 方法 ， 在 子 类 具体 实现 ， 另 外 就 是 对 使 用 当前 request 获 取 到 的 LocaleContext 和 
RequestAttributes 进 行 了 保存 ， 以 及 处 理 完 之 后 的 恢复 ， 在 最 后 发 布 了 ServletRequest-HandledEvent 事 件 。 


10.3 DispatcherServlet 


DispatcherServlet 是 Spring MVC 最 核心 的 类 ， 整 个 处 理 过 程 的 顶层 设计 都 在 这 里 面 ， 所 以 我 们 一 定 要 把 这 个 类 彻底 弄 明白 


通过 之 前 的 分 析 我 们 知道 ，DispatcherServlet 里 面 执 行 处 理 的 入 口 方法 应 该 是 doService， 不 过 doServic 并 没有 直接 进行 处 理 ， 而 是 交 给 了 doDispatch 进 行 具 体 的 处 理 ， 在 doDispatch 处 理 前 doServic 
此 


事情 : 首先 判断 是 不 是 include 请 求 ， 如 果 是 则 对 request 的 Attribute 做 个 快照 备份 ， 等 doDispatch 处 理 完 之 后 (如果 不 是 异步 调用 且 示 完成) 进行 还 原 ， 在 做 完 快 照 后 又 对 request 设 置 了 一 些 属 
性 ， 代 码 如 下 : 


// org.springframework.web.servlet .DispatcherServlet 


protected void doService (HttpServletRequest request, HttpServletResponse response) throws Exception { 
if (logger.isDebugEnabled()) { 


String resumed = WebAsyncUtils.getAsyncManager (request) .asConcurrentResult ()? " resumed" : ""; 
logger.debug ("DispatcherServlet with name '" + getServletName() + "'" + resumed + 
" processing " + request.getMethod() + " request for [" + getRequestUri (request) + "]"); 


// 当 include 请 求 时 对 request 的 Attribute 做 快照 备份 

Map<String, Object> attributesSnapshot = null; 

if (WebUtils.isIncludeRequest (request)) { 
attributesSnapshot = new HashMap<String, Object>(); 
Enumeration<?> attrNames = request .getAttributeNames (); 
while (attrNames.hasMoreElements()) { 


String attrName = (String) attrNames .nextElement (); 

if (this.cleanupAfterIinclude || attrName.startsWith ("org.springframework. web.servlet")) { 
attributesSnapshot .put (attrName, request.getAttribute (attrName)); 

} 


} 


} 
// 对 request 设 置 一 些 属性 


request .setAttribute (WEB APPLICATION CONTEXT _ ATTRIBUTE， getWebApplicationContext()); 
request .setAttribute (LOCALE RESOLVER ATTRIBUTE, this.localeResolver); 
request .setAttribute (THEMF, RESOLVER ATTRIBUTE, this.themeResolver); 
request .setAttribute (THEME SOURCE ATTRIBUTE, getThemeSource()); 
FlashMap inputFlashMap = this.flashMapManager.retrieveAndUpdate (request, response); 
if (inputFlashMap != null) { 
request.setAttribute (INPUT_ FLASH MAP ATTRIBUTE, Collections.unmodifiableMap (inputFlashMap)); 
} 
request.setAttribute (OUTPUT FLASH MAP ATTRIBUTE, new FlashMap()); 
request.setAttribute (FLASH MAP MANAGER ATTRIBUTE, this.flashMapManager); 
try { 
> doDispatch (request, response); 
}finally { 
if (!WebAsyncUtils.getAsyncManager (request) .isConcurrentHandlingStarted()) { 
// 还 原 request 快 照 的 属性 
if (attributesSnapshot != null) { 
restoreAttributesAfterInclude (request, attributesSnapshot); 
} 


对 request 设 置 的 属性 中 ， 前 面 4 个 属性 webApplicationContext、localeResolver、theme-Resolver 和 themeSource 在 之 后 介绍 的 handler 和 view 中 需要 使 用 ， 到 时 候 再 作 分 析 。 后 面 三 个 属性 都 和 
flashMap 相 关 ， 主 要 用 于 Redirect 转 发 时 参数 的 传递 ， 比 如 ， 为 了 避免 重复 提交 表单 ， 可 以 在 处 理 完 post 请 求 后 redirect 到 一 个 get 的 请 求 ， 这 样 即 使 用 户 刷新 也 不 会 有 重复 提交 的 问题 。 不 过 这 里 有 个 问 
题 ， 前 面 的 post 请 求 是 提交 订单 ， 提 交 完 后 redirect 到 一 个 显示 订单 的 页 面 ， 显 然 在 显示 订单 的 页 面 需要 知道 订单 的 一 些 信息 ， 但 redirect 本 身 是 没有 传递 参数 的 功能 的 ， 按 普通 的 模式 如 果 想 传递 参数 ， 就 
只 能 将 其 写 入 url 中 ， 但 是 url 有 长 度 限 制 ， 另 外 有 些 场 景 中 我 们 想 传递 的 参数 还 不 想 暴 露 在 url 里 ， 这 时 就 可 以 用 flashMap 来 进行 传递 了 ， 我 们 只 需要 在 redirect 之 前 将 需要 传递 的 参数 写 入 
OUTPUT FLAsH_MAP_ATTRIBUTE， 如 下 (这 里 使 用 了 前 面 讲 到 的 RequestContextHolder) : 


> 


((FlashMap) ( (ServletRequestAttributes) (RequestContextHolder.getRequestAttributes () ) ) .getRequest () .getAttribute (DispatcherServlet .OUTPUT FLASH MAP ATTRIBUTE)) .put ("name", " 张三丰 


这 样 在 redirect 之 后 的 handle 中 spring 就 会 自动 将 其 设置 到 model 里 ( 先 设置 到 INPUT_FLASH_MAP_ATTRIBUTE 属 性 里 ， 然 后 再 放 到 model 里 ) 。 当 然 这 样 操作 还 是 有 点 麻烦 ，spring 还 给 我 们 提供 
了 更 加 简单 的 操作 方法 ， 我 们 只 需要 在 handler 方 法 的 参数 中 定义 Redire-ctAttributes 类 型 的 变量 ， 然 后 把 需要 保存 的 属性 设置 到 里 面 就 行 ， 之 后 的 事情 spring 自 动 完成 。RedirectAttributes 有 两 种 设置 参 
数 的 方法 addAttribute (key，value) 和 addFlashAttribute (key，value) ， 用 第 一 个 方法 设置 的 参数 会 拼接 到 url 中 ， 第 二 个 方法 设置 的 参数 就 是 用 我 们 刚才 所 讲 的 flashMap 保 存 的。 比如 ， 一 个 提交 订 
单 的 Controller 可 以 这 么 写 : 


Q@ReaquestMapping (value = "/submit", method = RequestMethod. POST) 

public String submit (RedirectAttributes attr) throws IOException { 

((FlashMap) ( (ServletRequestAttributes) (RequestContextHolder.getRequestAttributes () ) ) .getRequest () .getAttribute (DispatcherServlet .OUTPUT FLASH MAP ATTRIBUTE)) .Put ("name ", " 张 三 
attr.addFlashAttribute ("ordersId", “xxx"); 
attr.addAttribute ("local", "zh-cn"); 
return "redirect:showorders "7 

} 

Q@RequestMapping (value = "/showorders", method = RequestMethod.GET) 

public String showOrders (Model model) throws IOException { 
doSomthinghttp://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/15447/0EBPS/Text/... 
return "orders"7 


这 里 分 别 使 用 了 三 种 方法 来 传递 redirect 参 数 : 


: 使 用 前 面 讲 过 的 RequestContextHolder 获 取 到 request， 并 从 其 属性 中 拿 到 output-FlashMapb， 然 后 将 属性 放 进 去 ， 当 然 request 可 以 直接 写 到 参数 里 让 Spring MVC 给 设置 进来 ， 这 里 主要 是 为 了 让 大 家 看 一 下 
使 用 RequestContextHolder 获 取 request 的 方法 。 


“ 通过 传 入 的 attr 参 数 的 addFlashAttribute 方 法 设置 ， 这 样 也 可 以 保存 到 output-FlashMap 中 ， 和 第 1 种 方法 效果 一 样 。 


通过 传 入 的 attt 参 数 的 addAttribute 方 法 设置 ， 这 样 设置 的 参数 不 会 保存 到 FlashMapb ， 而 是 会 拼接 到 ul 中。 


从 Request 获 取 outputFlashMap 除 了 直接 获取 DispatcherServlet.OUTPUT_FLASH_MAP_ATTRIBUTE 属 性 ， 还 可 以 使 用 RequestContextUtils 来 操作 : RequestContextUtils.getOutput- 
FlashMap (request) ， 这 样 也 可 以 得 到 outputFlashMap， 其 实 它 内 部 还 是 从 Request 的 属性 获取 的 。 


当 用 户 提交 http://xxx/submit 请 求 后 浏览 器 地 址 栏 会 自动 跳 转 到 http://xxx/showorders?Local=zh-cn 链 接 ， 而 在 showOrders 的 model 里 会 存在 ["name" "张三丰 "和 ["ordersld","xxx"] 两 个 属性 ， 而 
且 对 客户 端 是 透明 的 ， 用 户 并 不 知道 。 


这 就 是 flashMap 的 用 法 ，inputFlashMap 用 于 保存 上 次 请 求 中 转发 过 来 的 属性 ，output-FlashMap 用 于 保存 本 次 请 求 需要 转发 的 属性 ，FlashMapManager 用 于 管理 它们 ， 后 面 会 详细 分 析 
FlashMapManager。 


doService 就 分 析 完了 ， 在 这 里 主要 是 对 request 设 置 了 一 些 属性 ， 如 果 是 include 请 求 还 会 对 request 当 前 的 属性 做 快照 备份 ， 并 在 处 理 结束 后 恢复 。 最 后 将 请 求 转发 给 doDispatch 方 法 。 


doDispatch 方 法 也 非常 简洁 ， 从 顶层 设计 了 整个 请 求 处 理 的 过 程 。doDispatch 中 最 核心 的 代码 只 要 4 句 ， 它 们 的 任务 分 别 是 : @ 根 据 request 找 到 Handler; @ 根 据 Handler 找 到 对 应 的 
HandlerAdapter; @@ 用 HandlerAdapter 处 理 Handler; @ 调 用 processDispatchResult 方 法 处 理 上 面 处 理 之 后 的 结果 (包含 找到 View 并 泻 染 输出 给 用 户 ) ， 对 应 的 代码 如 下 : 


mappedHandler = getHandler (processedRequest); 

HandlerAdapter ha = getHandlerAdapter (mappedHandler.getHandler ()); 

mv = ha.handle (processedRequest, response, mappedHandler.getHandler ()); 
processDispatchResult (processedRequest, response, mappedHandler, mv, dispatchException); 


这 里 需要 解释 三 个 概念 : HandlerMapping、Handler 和 HandlerAdapter。 这 三 个 概念 的 准确 理解 对 于 Spring MVC 的 学 习 非 常 重要 。 如 果 对 这 三 个 概念 理解 得 不 够 透彻 ， 将 会 严重 影响 对 Spring 
MVC 的 理解 。 下 面 给 大 家 解释 一 下 : 


Handler: 也 就 是 处 理 器 ， 它 直接 对 应 着 MVC 中 的 C 也 就 是 Controller 层 ， 它 的 具体 表现 形式 有 很 多 ， 可 以 是 类 ， 也 可 以 是 方法 ， 如 果 你 能 想到 别 的 表现 形式 也 可 以 使 用 ， 它 的 类 型 是 Object。 我 们 前 
面 例子 中 标注 了 @RequestMapping 的 所 有 方法 都 可 以 看 成 一 个 Handler。 只 要 可 以 实际 处 理 请 求 就 可 以 是 Handler。 


HandlerMapping: 是 用 来 查找 Handler 的 ， 在 Spring MVC 中 会 处 理 很 多 请 求 ， 每 个 请 求 都 需要 一 个 Handler 来 处 理 ， 具 体 接收 到 一 个 请 求 后 使 用 哪个 Handler 来 处 理 呢 ? 这 就 是 HandlerMapping 要 
做 的 事情 。 


HandlerAdapter: 很 多 人 对 这 个 的 理解 都 不 准确 ， 其 实 从 名 字 上 就 可 以 看 出 它 是 一 个 Adapter， 也 就 是 适配器 。 因 为 Spring MVC 中 的 Handler 可 以 是 任意 的 形式 ， 只 要 能 处 理 请 求 就 OK， 但 是 Servlet 
需要 的 处 理 方 法 的 结构 却 是 固定 的 ， 都 是 以 request 和 response 为 参数 的 方法 (如 doService 方 法 ) 。 怎 么 让 固定 的 Servlet 处 理 方法 调用 灵活 的 Handler 来 进行 处 理 呢 ? 这 就 是 HandlerAdapter 要 做 的 事 
情 。 


通俗 点 的 解释 就 是 Handler 是 用 来 干 活 的 工具 ，HandlerMapping 用 于 根据 需要 干 的 活 找到 相应 的 工具 ，HandlerAdapter 是 使 用 工具 干 活 的 人 。 比 如 ，Handler 就 像 车 床 、 铣 床 、 电 火花 之 类 的 设 
备 ，HandlerMapping 的 作用 是 根据 加 工 的 需求 选择 用 什么 设备 进行 加 工 ， 而 HandlerAdapter 是 具体 操作 设备 的 工人 ， 不 同 的 设备 需要 不 同 的 工人 去 加 工 ， 车 床 需要 车 工 ， 铣 床 需要 铣工 ， 如 果 让 车 工 使 


铣床 干 活 就 可 能 出 问题 ， 所 以 不 同 的 Handler 需 要 不 同 的 HandlerAdapter 去 使 用 。 我 们 都 知道 在 干 活 的 时 候 人 是 柔性 最 强 、 灵 活 度 最 高 的 ， 同 时 也 是 问题 最 多 、 困 难 最 多 的 。Spring MVC 中 也 一 样 ， 在 九 
大 组 件 中 HandlerAdapter 也 是 最 复杂 的 ， 所 以 在 后 面 学 习 HandlerAdapter 的 时 候 要 多 留心 。 


另外 View 和 ViewResolver 的 原理 与 Handler 和 HandlerMapping 的 原理 类 似 。View 是 用 来 展示 数据 的 ， 而 ViewResolver 用 来 查找 View。 通 俗 地 讲 就 是 干 完 活 后 需要 写 报告 ， 写 报告 又 需要 模板 ( 比 
如 ， 是 调查 报告 还 是 验收 报告 或 者 是 下 一 步 工 作 的 请 示 等 ) ，View 就 是 所 需要 的 模板 ， 模 板 就 像 公文 里 边 的 格式 ， 内 容 就 是 Model 里 边 的 数据 ，ViewResolver 就 是 用 来 选择 使 用 哪个 模板 的 。 


现在 再 回 过 头 去 看 上 面 的 四 句 代 码 应 该 就 觉得 很 容易 理解 了 ， 它 们 分 别 是 : 使 用 HandlerMapping 找 到 干 活 的 Handler， 找 到 使 用 Handler 的 HandlerAdapter， 让 HandlerAdapter 使 用 Handler 干 活 ， 
干 完 活 后 将 结果 写 个 报告 交 上 去 (通过 View 展 示 给 用 户 ) 。 


10.4 doDispatch 结 构 


10.3 节 介绍 了 doDispatch 做 的 4 件 事 ， 不 过 只 是 整体 介绍 ， 本 节 详 细 分 析 doDispatch 内 部 的 结构 以 及 处 理 的 流程 。 先 来 看 doDispatch 的 代码 : 


// org.springframework.web.servlet.DispatcherServ1let 
protected void doDispatch (HttpServletRequest request, HttpServletResponse response) throws Exception { 
HttpServletRequest processedRequest = request; 
HandlerExecutionChain mappedHandler = null; 
boolean multipartRequestParsed = false; 
WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager (request); 
try { 
ModelAndView mv = null; 
Exception dispatchException = null; 
try { 
// 检查 是 不 是 上 传 请 求 
processedRequest = checkMultipart (request); 
multipartRequestParsed = (processedRequest != request); 
// 根据 request 找 到 Handler 
mappedHandler = getHandler (processedRequest); 


if (mappedHandler == null || mappedHandler.getHandler() 一 null) { 
noHandlerFound (processedRequest, response); 
return; 


} 
// 根据 Handler 找 到 HandlerAdapter 
HandlerAdapter ha = getHandlerAdapter (mappedHandler .getHandler ()); 
// 处 理 GET、HEAD 请 求 的 Last-Modified 
String method = request .getMethod(); 
boolean isGet = "GET".equals (method); 
if (isGet || "HEAD".equals (method)) { 
long lastModified = ha.getLastModified (request, mappedHandler.getHandler ()); 
if (logger.isDebugEnabled()) { 
logger.debug ("Last-Modified value for [" + getRequestUri (request) + "] is: " + lastModified); 


} 
if (new ServletWebRequest (request, response) .checkNotModified (lastModified) && isGet) { 
return; 


} 


} 

// 执 行 相应 Interceptor 的 preHandle 

if (!mappedHandler.applyPreHandle (processedRequest, response)) { 
return; 

} 

// HandlerAdapter 使 用 Handler 处 理 请 求 

mv = ha.handle (processedRequest, response, mappedHandler.getHandler()); 

// 如 果 需 要 异步 处 理 ， 直 接 返回 

if (asyncManager.isConcurrentHandl1ingStarted ()) { 
return; 


} 

// 当 view 为 空 时 (比如 ，Handler 返 回 值 为 void) ， 根 据 request 设 置 默认 view 

applyDefaultViewName (request, mv); 

// 执 行 相 应 Interceptor 的 postHandle 

mappedHandler .applyPostHandle (processedRequest, response, mv); 
}catch (Exception ex) { 

dispatchException = ex; 


} 
// 处 理 返回 结果 。 包 括 处 理 异 常 、 泻 染 页 面 、 发 出 完成 通知 触发 Interceptor 的 afterCompletion 
processDispatchResult (processedRequest, response, mappedHandler, mv, dispatchException); 
}catch (Exception ex) { 
triggerAfterCompletion (processedRequest, response, mappedHandler, ex); 
}catch (Error err) { 
triggerAfterCompletionWithError (processedRequest, response, mappedHandler, err); 
}finally { 
// 判断 是 否 执行 异步 请 求 
if (asyncManager.isConcurrentHandlingStarted()) { 
if (mappedHandler != null) { 
mappedHandler .applyAfterConcurrentHandlingStarted (processedRequest, response); 


Jelse { 
// 删除 上 传 请 求 的 资源 
if (multipartRequestParsed) { 
cleanupMultipart (processedRequest); 
} 


doDispatch 大 体 可 以 分 为 两 部 分 : 处 理 请 求 和 泻 染 页 面 。 开 头 部 分 先 定义 了 几 个 变量 ， 在 后 面 要 用 到 ， 如 下 : 


“ HttpServletRequest processedRequest: 实际 处 理 时 所 用 的 request， 如 果 不 是 上 传 请 求 则 直接 使 用 接收 到 的 request， 否 则 封装 为 上 传 类 型 的 request。 
HandlerExecutionChain mappedHandler: 处 理 请 求 的 处 理 器 链 (包含 处 理 器 和 对 应 的 Interceptor) 。 

“ boolean multipartRequestParsed: 是 不 是 上 传 请 求 的 标志 。 

: ModelAndView mv: 封装 Model 和 View 的 容器 ， 此 变量 在 整个 Spring MVC 处 理 的 过 程 中 承担 着 非常 重要 角色 ， 如 果 使 用 过 SpringMVC 就 不 会 对 ModelAndView 陌 生 。 


“ Exception dispatchException: 处 理 请 求 过 程 中 抛 出 的 异常 。 需 要 注意 的 是 它 并 不 包含 泻 染 过 程 抛 出 的 异常 。 


doDispatch 中 首先 检查 是 不 是 上 传 请 求 ， 如 果 是 上 传 请 求 ， 则 将 request 转 换 为 Multi-partHttpServletRequest， 并 将 multipartRequestParsed 标 志 设 置 为 true。 其 中 使 用 到 了 Multipart-Resolver。 


到 了 HandlerMapping， 返 回 值 为 HandlerExecutionChain 类 型 ， 其 中 包含 着 与 当前 request 相 匹配 的 Interceptor 和 Handler。getHandler 


然后 通过 getHandler 方 法 获取 Handler 处 理 器 链 ， 其 中 使 
代码 如 下 : 


// org.springframework.web.servlet .DispatcherServlet 
protected HandlerExecutionChain getHandler (HttpServletRequest request) throws Exception { 
for (HandlerMapping hm : this.handlerMappings) { 
if (logger.isTraceEnabled()) { 
logger.trace( 
"Testing handler map [" + hm + "] in DispatcherServlet with name '" + getServletName() + "™'"); 
} 
HandlerExecutionChain handler = hm.getHandler (request); 
if (handler != null) { 
return handler; 


} 


return null; 


方法 结构 非常 简单 ，HandlerMapping 在 后 
依次 执行 Interceptor 的 preHandle 方 法 ， 最 后 执行 
经 过 加 油 站 ， 但 两 次 所 经 过 的 顺序 是 相 


的 时 候 和 返回 的 时 候 都 要 经 


接 下 来 是 处 理 GET、HEAD 请 求 的 Last-Modified。 
候 修 改 的 。 在 浏览 器 以 后 发 送 请 求 时 会 同 
(同时 返回 新 的 Last-Modified) ， 否 则 直接 返回 


接 下 来 依次 调用 相应 Interceptor 的 preHandle。 


处 理 完 Interceptor 的 preHandle 后 就 到 了 此 方法 最 关键 的 地 方 一 一 让 HandlerAdapter 使 


详细 讲解 。 


Handler 处 理 完 请 求 后 ， 如 果 需 要 异步 处 理 ， 则 直接 返 
的 过 程 中 使 用 到 了 ViewNameTranslator。 


到 这 里 请 求 处 理 的 内 容 就 完成 了 ， 接 下 来 使 


我 们 先 来 说 一 下 doDispatch 的 异常 处 理 结构 。doDispatch 有 两 层 


面 详细 讲解 ，HandlerExecutionChain 的 类 型 类 似 3 


Handler 处 理 请 求 ，Controller 就 是 在 这 个 地 方 执 行 的 。 这 里 主要 使 用 了 HandlerAdapter， 具 体内 容 在 后 面 


processDispatchResult 方 法 处 理 前 面 返 区 


层 是 捕获 在 对 请 求 进 


Tomcat 中 讲 过 的 Pipeline，lnterceptor 和 Handler 相 当 于 那里 边 的 Value 和 Base-Value， 执 行 时 先 
反 的 顺序 执行 Interceptor 的 postHandle 方 法 。 就 好 像 要 去 一 个 地 方 ，Interceptor 是 要 经 过 的 收费 站 ，Handler 是 目的 地 ， 去 


当 浏 览 器 第 一 次 跟 服务 器 请 求 资源 (GET、Head 请 求 ) 时 ， 服 务 器 在 返回 的 请 求 头 里 面 会 包含 一 个 Last-Modified 的 属性 ， 代 表 本 资源 最 后 是 什么 时 
时 发 送 之 前 接收 到 的 Last-Modified， 服 务 器 接收 到 带 Last-Modified 的 请 求 后 会 用 其 值 和 自己 实际 资源 的 最 后 修改 时 间 做 对 比 ， 如 果 资 源 过 期 了 则 返回 新 的 资源 
304 状 态 码 表示 资源 未 过 期 ， 浏 览 器 直接 使 用 之 前 缓存 的 结果 


n0Handler 返 回 值 为 void) ， 设 置 默认 view， 然 后 执行 相应 Interceptor 的 postHandle。 设 置 默认 view 


回 的 结果 ， 其 中 包括 处 理 异 常 、 演 染 页 面 、 触 发 Interceptor 的 afterCompletion 方 法 三 部 分 内 容 。 


行 处 理 的 过 程 中 抛 出 的 异常 ， 外 层 主要 是 在 处 理 泻 染 页 面 时 抛 出 的 。 内 层 的 异常 ， 也 就 是 执行 请 求 


处 理 时 的 异常 会 设置 到 dispatchException 变 量 ， 然 后 在 processDispatchResult 方 法 中 进行 处 理 ， 外 层 则 是 处 理 processDispatchResult 方 法 抛 出 的 异常 。 processDispatchResult 代 码 如 下 : 


// org.springframework.web.servlet .DispatcherServlet 


private void processDispatchResult (HttpServletRequest request, HttpServletResponse response, 
HandlerExecutionChain PP an er ModelAndView mv, Exception exception) throws Exception { 


boolean errorView = fals: 
// 如 果 请 求 处 理 的 过 程 中 有 异 党 地 出 则 处 理 异 党 
if (exception != null) { 
if (exception instanceof ModelAndViewDefiningException) 
logger .debug ("ModelAndViewDefiningException encountered", exception); 
mv = ((ModelAndViewDefiningException) exception) .getModelAndView(); 


}else { 


Object handler = (mappedHandler != null ? mappedHandler.getHandler() : 
mv = processHandlerException (request, response, handler, exception); 
errorView = (m 


} 
} 
// 泻 数 页 面 


if (mv != null && !mv.wasClearedq()) 
render (mv, request, response); 

if (errorView) 
WebUtils.clearErrorRequestAttributes (request); 


} 


}else { 


if (logger.isDebugEnabled()) 


logger.debug ("Null ModelAndView returned to DispatcherServlet with name '" + getServletName() + 


} 


} 
if (WebAsyncUtils.getAsyncManager (request) .isConcurrentHandlingSstarted()) 
// 如 果 启 动 了 异步 处 理 则 返回 


return; 


} 
// 发 出 请 求 处 理 完成 的 通知 ， 触 发 Interceptor 的 afterCompletion 
if (mappedHandler != null) { 
mappedHandler .triggerAfterCompletion (request, response, null); 


’ 


可 以 看 到 processDispatchResult 处 理 异 常 的 方式 其 实 就 是 将 相应 的 错误 页 | 


泻 染 页 面具 体 在 render 方 法 中 执行 ， en eb 过 
实际 的 View， 最 后 调用 View 的 render 方 法 对 页 面 进 4 


doDispatch 方 法 就 分 析 完 了 。 可 以 看 到 Spring MVC 的 处 理 方式 


doDispatcher 的 处 理 流程 E 边 是 Interceptor 相 关 处 理 方法 


: assuming HandlerAdapter completed request handling"); 


面 设置 到 View， 在 : 


中 的 processHandlerException 方 法 中 用 到 了 HandlerExceptionResolver。 


到 了 LocaleResolver， 然 后 判断 View 如 果 是 String 类 型 则 调用 resolveViewName 方 法 使 用 ViewResolver 得 到 
， 泻 染 的 过 程 中 使 用 到 了 ThemeResolver。 


最 后 通过 mappedHandler 的 triggerAfterCompletion 方 法 触发 Interceptor 的 afterCompletion 方 法 ， 这 里 的 Interceptor 也 是 按 反方 向 执行 的 。 到 这 里 processDispatchResult 方 法 就 执行 完了 。 


里 ， 如 果 启 动 了 则 调 


再 返回 doDispatch 方 法 中 ， 在 最 后 的 finally 中 判断 是 否 请 求 启动 


层 设计 好 整体 结构 ， 然 后 将 具体 的 处 理 交 给 不 同 的 组 件 具体 去 实现 的 。doDispatcher 的 流程 
位 置 ， ee sy 图 中 上 半 部 分 的 处 理 请 求 对 应 着 MVC 中 的 Controller 也 就 是 C 层 ， 下 半 部 


分 的 processDispatchResult 了 


理解 doDispatcher 的 结构 之 , 


要 对 应 了 MVC 中 的 View 也 就 是 V 


发 过 程 中 如 果 遇 到 问题 ， 就 可 以 知道 是 在 哪 部 分 出 的 问题 ， 从 而 缩小 查找 范 


相应 异步 处 理 的 拦截 器 ， 和 否则 如 果 是 上 传 请 求 则 删除 上 传 请 求 过 程 中 产生 的 临时 资源 。 


网 


如 图 10-1 所 示 ， 中 间 是 


屋 也 就 是 Model 贯 穿 于 整个 过 程 中 。 


是 


， 有 的 放 矢 地 去 解决 。 


Interceptor 


preHandle *: 


postHandle < 


doDispath 


相关 组 件 


、 


、MultipartResolver 
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、 


» HandlerMapping 


执行 相应 


Interceptor 


的 preHandle 


HandlerAdapter 


使 用 Handler 处 ;» HandlerAdapter 


当 view 为 空 时 

( 比如 Handler 
返回 值 为 void) ， 
根据 request 设 
置 时 


执行 相应 


Interceptor 


的 postHandle 


-> 
N 


processDispatchResult 


10.5 小 结 


本 章 整体 分 析 了 Spring MVC 中 请 求 处 理 的 过 程 。 


三 个 Servlet 的 处 理 过 程 大 致 功能 如 下 : 


> HandlerExceptionResolver 


LocaleResolver 
>> ViewResolver 
ThemaResolver 


图 10-1 doDispatchet 方 法 处 理 流程 图 


首先 对 三 个 Servlet 进 行 了 分 析 ， 然 后 单独 分 析 了 DispatcherServlet 中 的 doDispatch 方 法 。 


“ HttpServletBean: 没有 参与 实际 请 求 的 处 理 。 

: FramewotkSetvlet: 将 不 同类 型 的 请 求 合并 到 了 processRequest 方 法 统一 处 理 ，processRequest 方 法 中 做 了 三 件 事 : 
“ 调用 了 doService 模 板 方法 有 具体 处 理 请 求 。 
“ 将 当前 请 求 的 LocaleContext 和 ServletRequestAttributes 在 处 理 请 求 前 设置 到 了 LocaleContextHolder 和 RequestContextHolder， 并 在 请 求 处 理 完成 后 恢复 ， 
“ 请 求 处 理 完 后 发 布 了 ServletRequestHandledEvent 消 息 。 


“ DispatcherServlet: doService 方 法 给 request 设 置 了 一 些 属性 并 将 请 求 交 给 doDispatch 方 法 有 具体 处 理 。 


DispatcherServlet 中 的 doDispatch 方 法 完成 Spring MVC 中 请 求 处 理 过 程 的 顶层 设计 ， 它 使 用 DispatcherServlet 中 的 九 大 组 件 完 成 了 具体 的 请 求 处 理 。 另 外 HandlerMapping、Handler 和 
HandlerAdapter 这 三 个 概念 的 含义 以 及 它们 之 间 的 关系 也 非常 重要 。 


第 三 篇 Spring MVC 组 件 分 析 


在 前 面 已 经 分 析 了 Spring MVC 整 体 的 结构 以 及 处 理 流程 ， 本 篇 对 每 个 具体 的 组 件 进行 详细 的 分 析 。 首 先 ， 介 绍 各 个 组 件 的 接口 、 功 能 和 用 法 ， 让 大 家 明白 它们 到 底 是 什么 ， 有 什么 用 ， 怎 么 用 ， 对 它们 
有 个 宏观 认识 ， 然 后 具体 对 每 个 组 件 的 各 种 实现 方式 进行 详细 分 析 。 


第 11 章 ”组件 概览 


本 章 的 内 容 主要 是 对 各 个 组 件 做 宏观 的 介绍 ， 让 大 家 知道 每 个 组 件 到 底 是 怎么 回 事 。 这 里 的 组 件 指 的 是 DispatcherServlet 中 直接 初始 化 的 那 九 个 组 件 ， 不 同 的 组 件 内 部 可 能 还 会 用 到 一 些 子 组 件 ， 那 些 
子 组 件 会 在 后 面 详细 分 析 九 大 组 件 的 过 程 中 同时 分 析 。 


11.1 HandlerMapping 


HandlerMapping 在 前 面 已 经 介绍 过 了 ， 它 的 作用 是 根据 request 找 到 相应 的 处 理 器 Handler 和 Interceptors，HandlerMapping 接 口 里 面 只 有 一 个 方法 。 


HandlerExecutionChain getHandler (HttpServletRequest request) throws Exception; 


方法 的 实现 非常 灵活 ， 只 要 使 用 Request 返 回 HandlerExecutionChain 就 可 以 了 。 我 们 也 可 以 自己 定义 一 个 HandlerMapping， 然 后 实现 getHandler 方 法 。 比 如 ， 可 以 定义 一 个 Tudou- 
HandlerMapping， 将 以 tudou 开 头 的 请 求 对 应 到 digua 的 处 理 器 去 处 理 ， 只 需要 判断 请 求 的 url: 如 果 是 以 tudou 开 头 那 么 就 返回 地 瓜 的 Handler。 如 果 想 更 进一步 还 可 以 再 细 分 ， 如 将 tudou 开 头 的 Get 请 
求 对 应 到 maidigua ( 卖 地 瓜 ) ， 而 Post 请 求 对 应 到 shoudigua ( 收 地 瓜 ) ， 其 他 类 型 全 部 交 给 digua 处 理 器 ， 程 序 代码 如 下 : 


public class DiguaHandlerMapping implements HandlerMapping { 
QOverride 
public HandlerExecutionChain getHandler (HttpServletRequest request) throws Exception { 
String Url = request .getRequestURI () .上 toString () 7 
String method = request.getMethod(); 
if(url.startsWith("/tudou")){ 
if (method.equalsIgnoreCase ("GET")) 
return "maidigua" 对 应 的 Handler; 
else if (method.equalsIgnoreCase ("POST")) 
return "shoudigua" 对 应 的 Handler; 
else 
return "digua" 对 应 的 Handler; 


return null; 


当然 ， 这 只 是 一 个 为 了 说 明 原 理 的 伪 代 码 ， 并 不 能 实际 使 用 ， 因 为 并 没有 实际 创建 Handler， 另 外 返回 值 除 了 有 Handler 还 应 该 包含 Interceptor。 这 里 的 HandlerMapping 只 能 查找 “tudou” 相 关 的 
Handler， 而 更 一 般 的 做 法 是 维护 一 个 对 应 多 个 请 求 的 map， 其 实 SimpleUrlHandlerMapping 的 基本 原理 就 是 那样 。HandlerMapping 编 写 出 来 后 需要 注册 到 Spring MVC 的 容器 里 面 才 可 以 使 用 ， 注 册 也 
非常 简单 ， 只 需要 在 配置 文件 里 配置 一 个 Bean 就 可 以 了 ，Spring MVC 会 按照 类 型 将 它 注册 到 HandlerMapping 中 ， 这 些 前 面 已 经 介绍 过 了 。 


其 实 这 里 忽略 了 一 个 问题 。 在 上 面 将 所 有 以 tudou 开 头 的 请 求 都 对 应 到 了 digua 相 关 的 处 理 器 ， 好 像 没什么 问题 ， 但 是 如 果 有 个 专门 处 理 tudoupian (土豆 片 ) 的 处 理 器 (处 理 以 tudoupian 开 头 的 
url) ， 而 且 是 在 另外 的 HandlerMapping 中 进行 的 映射 ， 这 就 涉及 先 使 用 哪个 HandlerMapping 来 查找 处 理 器 的 问题 了 ， 如 果 先 使 用 了 TudouHandlerMapping 就 会 将 tudoupian 的 请 求 也 交 给 tudou 的 处 
理 器 ， 这 样 就 出 问题 了 ! 这 时 候 使 用 HandlerMapping 的 顺序 就 非常 重要 了 ， 这 里 的 顺序 可 以 通过 order 属 性 来 定义 (当然 HandlerMapping 需 要 实现 Order 接 口 ) ，order 越 小 越 先 使 用 ， 比 如 : 


<bean class="com.excelib.TudouHandlerMapping" 
p:order="1"/> 

<bean class="com.excelib.TudoupianHandlerMapping" 
p:order="0"/> 


查找 Handler 是 按 顺 序 遍 历 所 有 的 HandlerMapping， 当 找到 一 个 HandlerMapping 后 立即 停止 查找 并 返回 ， 代 码 如 下 : 


// org.springframework.web.servlet .DispatcherServlet 
protected HandlerExecutionChain getHandler (HttpServletRequest request) throws Exception { 
for (HandlerMapping hm : this.handlerMappings) { 
if (logger.isTraceEnabled()) { 
logger.trace( 
"Testing handler map [" + hm + "] in DispatcherServlet with name '" + getServletName() + "™'"); 


} 
HandlerExecutionChain handler = hm.getHandler (request); 
if (handler != null) { 

return handler; 


} 


return null; 


HandlerMapping 的 接口 以 及 用 法 就 介绍 完了 ， 在 Spring MVC 中 HandlerMapping 具 体 是 怎么 实现 的 ， 后 面 再 详细 分 析 。 


11.2 HandlerAdapter 


HandlerAdapter 在 前 面 也 介绍 过 了 ， 可 以 理解 为 使 用 处 理 器 干 活 的 人 。 它 里 面 一 共 三 个 方法 ，supports (Object handler) 判断 是 否 可 以 使 用 某 个 Handler; handler 方 法 是 用 来 具体 使 用 Handler 
活 ; getLastModified 是 获取 资源 的 Last-Modified，Last-Modified 是 资源 最 后 一 次 修改 的 时 间 ， 前 面 已 经 介绍 过 了 。HandlerAdapter 接 口 定义 如 下 : 


Package org.springframework.web.servlet; 

import javax.servlet.http.HttpServletRequest; 

import javax.servlet.http.HttpServletResponse; 

public interface HandlerAdapter { 
boolean supports (Object handler); 
ModelAndView handle (HttpServiletRequest request, HttpServletResponse response, Object handler) throws Exception; 
long getLastModified (HttpServletRequest request, Object handler); 


之 所 以 要 使 用 HandlerAdapter 是 因为 Spring MVC 中 并 没有 对 处 理 器 做 任何 限制 ， 处 理 器 可 以 以 任意 合理 的 方式 来 表现 ， 可 以 是 一 个 类 ， 也 可 以 是 一 个 方法 ， 还 可 以 是 别 的 合理 的 方式 ， 从 handle 方 法 
可 以 看 出 它 是 Object 的 类 型 。 这 种 模式 就 给 开发 者 提供 了 极 大 的 自由 。 


接着 前 面 的 例子 写 一 个 HandlerAdapter， 首 先 写 一 个 MaiDiguaController 处 理 器 ， 然 后 再 写 对 应 的 HandlerAdapter， 代 码 如 下 : 


package com.excelib.controller; 
// 上 省略 了 imports 
public class MaiDiguaController { 
public ModelAndView maidigua (HttpServletRequest request, HttpServletResponse response) { 
// 拒 地 瓜 ; 挑 大 的 、 国 的 …… 
// 称 重 ; 放 到 称 上 称 重 
// 算 钱 ; 单 价 x 重量 算出 来 价钱 抹 去 零头 ， 给 人 留 个 好 印象 老 顾客 可 以 来 点 折扣 …… 
i 
} 
Package com.excelib.servlet; 
// 省 略 了 imports 
public class MaiDiguaHandlerAdapter implements HandlerAdapter 
{ 
QOverride 
public boolean supports (Object handler) { 
return handler instanceof MaiDiguaController; 
} 
Override 
public ModelAndView handle (HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { 
return ((MaiDiguaController)handler) .maidigua (request, response); 
} 
QOverride 
public long getLastModified (HttpServletRequest request, Object handler) { 
return -1L; 


} 


这 里 写 了 一 个 卖 地 瓜 的 Handler 一 一 MaiDiguaController， 用 来 具体 处 理 卖 地 瓜 这 件 事情 ，MaiDiguaHandlerAdapter 使 用 MaiDiguaController 完 成 卖 地 瓜 这 件 事 ， 当 然 这 里 只 是 简单 地 调 


下 面 再 看 一 个 Spring MVC 自 己 的 HandlerAdapter 一 一 SimpleControllerHandlerAdapter， 代 码 如 下 : 


Package org.springframework.web.servlet .mve; 
// 省 略 了 imports 
public class SimpleControllerHandlerAdapter implements HandlerAdapter { 
QOverride 
Public boolean supports (Object handler) { 
return (handler instanceof Controller); 
} 
QOverride 
public ModelAndView handle (HttpServletRequest request, HttpServletResponse response, Object handler) 
throws Exception { 
return ((Controller) handler) .handleRequest (request, response); 
} 
QOverride 
public long getLastModified (HttpServletRequest request, Object handler) { 
if (handler instanceof LastModified) { 
return ((LastModified) handler) .getLastModified (request); 
} 


return -1L; 


可 以 看 到 这 个 Adapter 也 非常 简单 ， 是 用 来 使 用 实现 了 Controller 接 口 的 处 理 器 干 活 的 ， 干 活 的 方法 是 直接 调用 处 理 器 的 handleRequest 方 法 。 


选择 使 用 哪个 HandlerAdapter 的 过 程 在 getHandlerAdapter 方 法 中 ， 它 的 逻辑 是 遍历 所 有 的 Adapter， 然 后 检查 哪个 可 以 处 理 当前 的 Handler， 找 到 第 一 个 可 以 处 理 Handler 的 Adapter 后 就 停止 查找 
并 将 其 返回 。 就 好 像 公司 里 面 要 立 个 项 目 ， 项 目 需要 有 人 去 做 ， 交 给 谁 呢 ? 这 时 可 以 列 一 个 名 单 ， 挨 个 看 谁 可 以 做 ， 找 到 第 一 个 可 以 做 的 就 让 他 去 做 。 既 然 需要 挨个 检查 ， 那 就 需要 有 一 个 顺序 ， 这 里 的 顺 
序 同样 是 通过 Order 属 性 来 设置 的 。getHandlerAdapter 方 法 代码 如 下 : 


// org.springframework.web.servlet.DispatcherServV1let 
protected HandlerAdapter getHandlerAdapter (Object handler) throws ServletException { 
for (HandlerAdapter ha : this.handlerAdapters) { 
if (logger.isTraceEnabled()) { 
logger.trace ("Testing handler adapter [" + ha + "]"); 


if (ha.supports (handler)) { 
return ha; 
} 
} 
throw new ServletException ("No adapter for handler [" + handler + 
"] : The DispatcherServlet configuration needs to include a HandlerAdapter that supports this handler"); 


HandlerAdapter 需 要 注册 到 Spring MVC 的 容器 里 ， 注 册 方 法 和 HandlerMapping 一 样 ， 只 要 配置 一 个 Bean 就 可 以 了 。Handler 是 从 HandlerMapping 里 返回 的 。 


11.3 HandlerExceptionResolver 


别 的 组 件 都 是 在 正常 情况 下 用 来 干 活 的 ， 不 过 干 活 的 过 程 中 难免 会 出 现 问 题 ， 出 问题 后 怎么 办 呢 ? 这 就 需要 有 一 个 专门 的 角色 对 异常 情况 进行 处 理 ， 在 Spring MVC 中 就 是 


HandlerExceptionResolver。 具 体 来 说 ， 此 组 件 的 作用 是 根据 异常 设置 ModelAndView， 之 后 再 交 给 render 方 法 进行 泻 染 。render 只 负责 将 ModelAndView 泻 染 成 页 面 ， 具 体 ModelAndView 是 怎么 来 的 
render 并 不 关心 。 这 也 是 Spring MVC 设 计 优秀 的 一 个 表现 一 一 分 工 明确 互 不 干涉 。 通 过 前 面 doDispatcher 的 分 析 可 以 知道 HandlerExceptionResolver 只 是 用 于 解析 对 请 求 做 处 理 的 过 程 中 产生 的 异常 ， 而 
泻 染 环节 产生 的 异常 不 归 它 管 ， 现 在 我 们 就 知道 原因 了 : 它 是 在 render 之 前 工作 的 ， 先 解析 出 ModelAndView 之 后 render 才 去 泻 染 ， 当 然 它 就 不 能 处 理 render 过 程 中 的 异常 了 。 知 道 了 这 一 点 可 以 为 我 们 
分 析 一 些 问题 提供 方便 。HandlerExceptionResolver 接 口 定义 如 下 : 


Package org.springframework.web.servlet; 
import javax.servlet.http.HttpServletRequest; 
import javax.servlet.http.HttpServletResponse; 
public interface HandlerExceptionResolver { 
ModelAndView resolveException( 
HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex); 


HandlerExceptionResolver 结 构 非 常 简单 ， 只 有 一 个 方法 ， 只 需要 从 异常 解析 出 Model-AndView 就 可 以 了 。 具 体 实现 可 以 维护 一 个 异常 为 key、View 为 value 的 Map， 解 析 时 直接 从 Map 里 获取 
View， 如 果 在 Map 里 没有 相应 的 异常 可 以 返回 默认 的 View， 这 里 就 不 举例 子 了 。 另 外 建议 如 果 开 发 内 网 的 系统 则 可 以 在 出 错 页 面 显示 一 些 细节 ， 这 样 方便 调试 ， 但 如 果 是 做 互联 网 的 系统 最 好 不 要 将 异常 
的 太 多 细节 显示 给 用 户 ， 因 为 那样 很 容易 被 黑客 利用 。 当 然 ， 无 论 给 不 给 异常 页 面 显示 细节 ， 日 志 都 要 做 得 尽 可 能 详细 。 


回 


11.4 ViewResolver 


ViewResolver 用 来 将 String 类 型 的 视图 名 (有 的 地 方 也 叫 逻辑 视图 ， 都 指 同一 个 东西 ) 和 Locale 解 析 为 View 类 型 的 视图 ，ViewResolve 接 口 也 非常 简单 ， 只 有 一 个 方法 ， 定 义 如 下 : 


package org.springframework.web.servlet; 
import java.util.Locale; 
public interface ViewResolver { 
View resolveViewName (String viewName, Locale locale) throws Exception; 


i 


出 


从 接口 方法 的 定义 可 以 看 出 解析 视图 所 需 的 参数 是 视图 名 和 Locale， 不 过 一 般 情况 下 我 们 只 需要 根据 视图 名 找到 对 应 的 视图 ， 然 后 泻 染 就 行 ， 并 不 需要 对 不 同 的 区 域 使 用 不 同 的 视图 进行 显示 ， 如 果 需 
国际 化 支持 也 只 要 将 显示 的 内 容 或 者 主题 使 用 国际 化 支持 (具体 方法 在 后 面 讲述 ) ， 不 过 Spring MVC 确 实 有 这 个 功能 ， 可 以 让 不 同 的 区 域 使 用 不 同 的 视图 进行 显示 。ResourceBundleViewResolver 就 需 
同时 使 用 视图 名 和 Locale 来 解析 视图 。ResourceBundleViewResolver 需 要 将 每 一 个 视图 名 和 对 应 的 视图 类 型 配置 到 相应 的 properties 文 件 中 ， 默 认 使 用 classpath 下 的 views 为 baseName 的 配置 文件 ， 
如 views.properties、views zh_CN.properties 等 ，baseName 和 文件 位 置 都 可 以 设置 。 对 ResourceBundle 熟 悉 的 读者 应 该 已 经 明白 了 ， 不 同 的 Locale 会 使 用 不 同 的 配置 文件 ， 而 且 它 们 之 间 没有 任何 关 


系 ， 这 样 就 可 以 让 不 同 的 区 域 使 用 不 同 的 View 来 进行 泻 染 了 


[ 


View 是 用 来 泻 染 页 面 的 ， 通 俗 点 说 就 是 要 将 程序 返回 的 参数 填 入 模板 里 ， 生 成 html (也 可 能 是 其 他 类 型 ) 文件 。 这 里 有 两 个 关键 的 问题 


“ 使 用 哪个 模板 ? 


“ 用 什么 技术 (或 者 规则 ) 填 入 参数 ? 


这 其 实 就 是 ViewResolver 主 要 要 做 的 工作 ，ViewResolver 需 要 找到 泻 染 所 用 的 模板 和 所 用 的 技术 (也 就 是 视图 的 类 型 ) 进行 泻 染 ， 具 体 的 演 染 过 程 则 交 给 不 同 的 视图 自己 完成 。 我 们 最 常 使 用 的 
UrlBasedViewResolver 系 列 的 解析 器 都 是 针对 单一 视图 类 型 进行 解析 的 ， 只 需要 找到 使 用 的 模板 就 可 以 了 ， 比 如 ，InternalResourceViewResolver 只 针对 jsp 类 型 的 视图 ，FreeMarkerViewResolver 只 针 
对 FreeMarker，VelocityViewResolver 只 针对 Velocity。 而 ResourceBundleViewResolver、XmlViewResolver、BeanNameViewResolver 等 解析 器 可 以 同时 解析 多 种 类 型 的 视图 。 如 前 面 说 过 的 
ResourceBundleViewResolver， 它 是 根据 properties 配 置 文件 来 解析 的 ， 配 置 文件 里 就 需要 同时 配置 class 和 url 两 项 内 容 ， 比 如 : 


hello. (class)=org.springframework.Web.servlet .view.InternalResourceView 
hello.url=/WEB-INF/go.jsp 


这 样 就 将 hello 配 置 到 /WEB-INF/go.jsp 模 板 的 jsp 类 型 的 视图 了 ， 当 Controller 返 回 hello 时 会 使 用 这 个 视图 来 进行 泻 染 。 这 里 的 jsp 类 型 并 不 是 根据 go.jsp 的 后 绎 来 确定 的 ， 这 个 后 绎 只 是 个 文件 名 ,可 
以 把 它 改 成 任意 别 的 格式 ， 视 图 的 类 型 是 根据 .class 的 配置 项 来 确定 的 。 


XmlViewResolver 与 ResourceBundleViewResolver 类 似 ， 只 不 过 它 是 使 用 xml 文 件 来 配置 的 。BeanNameViewResolver 是 根据 ViewName 从 ApplicationContext 容 器 中 查找 相应 的 bean 做 View 的 ， 
这 个 实现 比较 简单 ， 我 们 来 看 一 下 它 的 源码 。 


Package org.springframework.web.servlet .view; 
// 省 略 了 imports 
public class BeanNameViewResolver extends WebApplicationObjectSupport implements ViewResolver, Ordered { 
private int order = Integer.MAX VALUE; // default: same as non-Ordered 
public void setOrder (int order) { 
this.order = order; 


} 
QOverride 
public int getOrder() { 

return this.order; 
QOverride 
public View resolveViewName (String viewName, Locale locale) throws BeansException { 

ApplicationContext context = getApplicationContext (); 

if (!context.containsBean (viewName)) { 

if (logger.isDebugEnabled()) { 
logger.debug ("No matching bean found for View name '" + ViewName + "™'"); 


i 
// Allow for ViewResolver chaininghttp://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/15447/0EBPS/Text/... 
return null; 


} 
if (!context.isTypeMatch (viewName, View.class)) { 
if (logger.isDebugEnabled()) { 
logger.debug ("Found matching bean for view name '" + viewName + 
"' =- to be ignored since it does not implement View"); 
} 
// Since we're looking into the general ApplicationContext here, 
// let's accept this as a non-match and allow for chaining as wellhttp://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/15447/OEBPE 
return null; 
} 


return context .getBean (viewName, View.class); 


} 


可 以 看 到 其 原理 就 是 根据 viewName 从 spring 容 器 中 查找 Bean， 如 果 查 找 不 到 或 者 查 到 后 不 是 View 类 型 则 返回 null， 否 则 返回 容器 中 的 bean。 


ViewResolver 的 使 用 需要 注册 到 Spring MVC 的 容器 里 ， 默 认 使 用 的 是 org.spring-framework.web.servlet.view.InternalResourceViewResolver。 


11.5 RequestToViewNameTranslator 


ViewResolver 是 根据 ViewName 查 找 View， 但 有 的 Handler 处 理 完 后 并 没有 设置 View 也 没有 设置 viewName， 这 时 就 需要 从 request 获 取 viewName 了 ， 而 如 何 从 request 获 取 view-Name 就 是 


RequestToViewNameTranslator 要 做 的 事情 。RequestToViewNameTranslator 接 口 定义 如 下 : 


package org.springframework.web.servlet; 
import javax.servlet.http.HttpServletRequest; 
public interface RequestToViewNameTranslator { 
String getViewName (HttpServletRequest request) throws Exception; 
} 


其 中 只 有 一 个 getViewName 方 法 ， 只 要 通过 request 获 取 到 viewName 就 可 以 了 。 我 们 来 定义 一 个 Translator， 其 中 判断 如 果 是 tudou 的 Get 请 求 则 返回 


viewName。 


“maidigua” 否 则 返回 


“404" 作为 


Public class MaiDiguaRequestToViewNameTranslator implements RequestToViewNameTranslator { 
QOverride 
public String getViewName (HttpServletRequest request) throws Exception { 
if (request .getRequestURI () .tostring() .startsWith ("/tudou") &g&request .getMethod () .equalsIgnoreCase ("GET")) 
return "maidigua"; 
else 
return "404"; 


时 应 该 设置 规则 而 不 是 将 某 个 具体 请 求 与 ViewName 的 对 应 关系 硬 编码 到 程序 里 面 ， 那 样 才 可 以 


当然 ， 这 里 只 是 一 个 例子 ， 实 际 使 


备 更 好 的 通用 性 。 


RequestToViewNameTranslator 在 Spring MVC 容 器 里 只 可 以 配置 一 个 ， 所 以 所 有 request 到 ViewName 的 转换 规则 都 要 在 一 个 Translator 里 面 全 部 实现 。 


11.6 LocaleResolver 


而 


解析 视图 
要 做 的 事情 。 


两 个 参数 : 一 个 是 视图 


名 ， 另 一 个 是 Locale。 视 图 


名 是 处 理 器 返回 的 (或 者 使 用 RequestToViewNameTranslator 解 析 的 默认 视图 


于 从 request 解 析出 Locale。Locale 在 前 面 已 经 介绍 过 ， 就 是 zh-cn 之 类 ， 表 示 一 个 区 域 。 有 了 这 个 就 可 以 对 不 同 区 域 的 F 
理 ，LocaleResolver 是 i18n 的 基础 。LocaleResolver 接 口 定义 如 下 : 


LocaleResolver, 


H 


户 显示 不 同 的 结果 ， 这 就 是 i18n ( 


名 ) ，Locale 是 从 哪里 来 的 呢 ? 这 就 是 LocaleResolver 


际 化 ) 的 基本 原 


Package org.springframework.web.servlet; 
// 省 略 了 imports 
Public interface LocaleResolver { 
Locale resolveLocale (HttpServletRequest request); 
void setLocale (HttpServletRequest request, HttpServletResponse response, Locale locale); 
} 


接口 
中 ， 代 码 如 下 : 


request .setAttribute (LOCALE RESOLVER ATTRIBUTE, this.localeResolver); 


定义 非常 简单 ， 只 有 2 个 方法 ， 分 别 表 示 : 从 request 解 析出 Locale 和 将 特定 的 Locale 设 置 给 某 个 request。 在 之 前 介绍 doService 方 法 时 说 过 ， 容 器 会 将 localeResolver 设 置 到 request 的 attribute 


这 样 就 让 我 们 在 需要 使 用 Locale 的 时 候 可 以 直接 从 request 拿 到 localeResolver， 然 后 解析 出 Locale。 

Spring MVC 中 主要 在 两 个 地 方 用 到 了 Locale: @ViewResolver 解 析 视 图 的 时 候 ; @ 使 用 到 国际 化 资源 或 者 主题 的 时 候 。ViewResolver 在 前 面 已 经 讲 过 ， 这 里 不 再 重 述 了 ， 国 际 化 资源 和 主题 主要 使 
RedquestContext 的 getMessage 和 getThemeMessage 方 法 。<spring:mess-age= “.…”/> 标 签 内 部 其 实 就 是 使 用 的 RequestContext， 只 不 过 没有 直接 调用 getMessage 而 是 先 调 用 了 
getMessageSource 然 后 在 内 部 又 调用 了 getMessage， 详 细 代 码 见 org.spring-framework.web.servlet.tags.MessageTag。 


LocaleResolver 的 作用 我 们 已 经 清楚 了 ， 不 过 有 时 候 需要 提供 人 为 设置 区 域 的 功能 ， 比 如 很 多 网 站 可 以 选择 显示 什么 语言 ， 这 就 需要 提供 人 为 修改 Loca 


e 的 机 制 。 在 Spring MVC 中 非常 简单 ， 


调用 LocaleResolver 的 setLocale 方 法 即 可 。 可 是 在 哪里 调用 呢 ? 我 们 可 以 写 一 个 Controller 来 专门 修改 Locale， 不 过 那样 使 用 起 来 比较 麻烦 ， 返 加 
吧 ! 即使 将 原来 的 地 址 通过 参数 传 入 也 会 有 问题 ， 比 如 ， 原 来 是 动态 页 面 ， 那 么 只 传递 地 址 就 会 有 问题 。 如 果 能 在 正常 请 求 的 
的 读者 肯定 已 经 想到 了 lnterceptor， 是 的 ， 使 用 Interceptor 就 可 以 做 到 这 一 点 。 幸 运 的 是 Spring MVC 已 经 写 好 了 ， 我 们 只 需要 配置 进去 就 可 以 了 ， 这 就 是 
org.springframework.web.servlet.i18n.LocaleChangelnterceptor， 配 置 方法 如 下 : 


只 需要 


的 视图 不 容易 确定 ， 总 不 能 说 一 切换 语言 就 跳 转 到 首页 
同时 对 Locale 做 修改 就 好 了 ， 而 且 每 个 请 求 都 要 可 以 修改 ! 熟悉 Spring MVC 


<mvc:interceptors> 
<mvc :intercePtor> 
<mvc:mapping path="/*" /> 
<bean class="org.springframework.web.servlet.il8n.LocaleChangeInterceptor" /> 
</mvc:interceptor> 
</mvc:interceptors> 


这 样 就 可 以 通过 locale 参 数 来 修改 Locale 了， 比如 
http://localhost:8080?locale=zh_CN 
http://localhost:8080?locale=en 


这 里 的 “locale” 也 可 以 通过 paramName 设 置 为 别 的 名 称 ， 如 设置 为 “lang”。 


<mvc:interceptors> 
<mvce:interceptor> 
<mvc:mapping path="/*" /> 
<bean class="org.springframework.web.servlet.il8n.LocaleChangeInterceptor" 
p:paramName="lang"/> 
</mvc:interceptor> 
</mvc:interceptors> 


11.7 ThemeResolver 


ThemeResolver 从 名 字 就 可 以 看 出 是 解析 主题 用 的 。ThemeResolver 接 口 定义 如 下 : 


package org.springframework.web.servlet; 
import javax.servlet.http.HttpServletRequest; 
import javax.servlet.http.HttpServletResponse; 
public interface ThemeResolver { 


String resolveThemeName (HttpServletRequest request); 
void setThemeName (HttpServletRequest request, HttpServletResponse response, String themeName); 


} 


以 前 使 用 电脑 的 时 候 可 能 很 多 人 都 没 注意 过 “主题 ”， 不 过 随 着 智能 手机 的 普及 ， 主 题 已 经 成 了 一 个 不 需要 过 多 解释 的 名 词 。 不 同 的 主题 其 实 就 是 换 了 一 套 


片 、 显 示 效果 以 及 样式 等 。Spring MVC 


[ 


中 一 套 主题 对 应 一 个 properties 文 件 ， 里 面 存放 着 跟 当 前 主题 相关 的 所 有 资源 ， 如 图 片 、css 样 式 表 等 ， 例 如 : 


#theme .properties 
logo.pic=/images/default/10go.jpg 
logo.word=excelib 
style=/css/default/style.css 


将 上 面 的 文件 命名 为 theme.properties， 放 到 classpath 下 面 就 可 以 在 页 面 中 使 用 了 ， 如 果 在 jsp 页 面 中 ,使 用 <spring:theme code= "logo.word"/> 就 可 以 得 到 excelib 了 (当然 ， 需 要 在 文件 开头 引入 
spring 自 己 的 标签 库 <%@taglibprefix="spring"uri="http://www.springframework.org/tags"%>) 。 现 在 所 用 的 主题 名 就 叫 theme， 主 题名 也 就 是 文件 名 ， 所 以 创建 主题 非常 简单 ， 只 需要 准备 好 资 
源 ， 然 后 新 建 一 个 以 主题 名 为 文件 名 的 properties 文 件 并 将 资源 设置 进去 就 可 以 了 。 另 外 ，Spring MVC 的 主题 也 支持 国际 化 ， 也 就 是 说 同一 个 主题 不 同 的 区 域 也 可 以 显示 不 同 的 风格 ， 比 如 ， 可 以 定义 以 下 


主题 文件 


theme .Properties 
theme_zh_CN.Properties 
theme_en_US .Properties… 


这 样 即使 同样 使 用 theme 的 主题 ， 不 同 的 区 域 也 会 调 有 


不 同 主题 文件 里 的 资源 进行 显示 。 


Spring MVC 中 跟 主 题 有 关 的 类 主要 有 ThemeResolver、ThemeSource 和 Theme。 从 上 面 的 接口 可 以 看 出 ，ThemeResolver 的 作用 是 从 request 解 析出 主题 名 ; ThemeSource 则 是 根据 主题 名 找到 


体 的 主题 ; Theme 是 ThemeSource 找 出 的 一 个 具体 的 主题 ， 可 以 通过 它 获 取 主 题 里 具体 的 资源 。 获 取 主 题 的 资源 依然 是 在 RequestContext 中 ， 代 码 如 下 : 


// org.springframework.web.servlet .support .RequestContext 
public String getThemeMessage (String code, Object[] args, String defaultMessage) { 
return getTheme () .getMessageSource () .getMessage (code, args, defaultMessage, this.locale); 


} 
public Theme getTheme () { 
if (this.theme == null) { 


this .theme = RequestContextUtils.getTheme (this.request); 


if (this.theme == null) { 
this.theme = getFallbackTheme (); 
} 


return this.theme; 


可 以 看 到 这 里 首先 通过 RequestContextUtils 获 取 到 Theme， 然 后 获取 对 应 的 资源 ， 再 看 一 下 RequestContextUtils 是 怎么 获取 Theme 的 : 


// org.springframework.web.servlet.support.RequestContextUtils 
public static Theme getTheme (HttpServletRequest request) { 
ThemeResolver themeResolver = getThemeResolver (request); 
ThemeSource themeSource = getThemeSource (request); 
if (themeResolver != null && themeSource != null) { 
String themeName = themeResolver.resolveThemeName (request); 


return themeSource.getTheme (themeName); 
}else { 
return null; 


} 


从 这 里 就 可 以 清楚 地 看 到 ThemeResolver 和 ThemeSource 的 作用 。ThemeResolver 的 默认 实现 是 org.springframework.web.servlet.theme.FixedThemeResolver， 这 里 边 使 用 的 默认 主题 名 就 


叫 “theme”， 这 也 就 是 前 面 使 用 theme 主 题 时 不 用 配置 也 可 以 使 用 的 原因 。 从 Dispatcher-Servlet 中 可 以 看 到 ThemeResolver 默 认 使 用 的 是 WebApplicationContext。 


在 讲 Spring MVC 容 器 创建 时 介绍 过 WebApplicationContext 是 在 FrameworkServlet 中 创建 的 ， 默 认 使 用 的 是 XmlWebApplicationContext， 其 父 类 是 


AbstractRefreshableWebApplicationContext， 这 个 类 实现 了 ThemeSource 


， 其 实现 方式 是 在 内 部 封装 了 一 个 ThemeSource 属 性 ， 然 后 将 具体 工作 交 给 它 去 干 。 


现在 我 们 就 把 整个 原理 弄 明白 了 : 主题 是 通过 一 系列 资源 来 具体 体现 的 ， 要 得 到 一 个 主题 的 资源 ， 首 先 要 得 到 资源 的 名 称 ， 这 个 是 ThemeResolver 的 工作 ， 然 后 用 资源 名 称 找到 主题 (可 以 理解 为 一 个 


配置 文件 ) ， 这 是 ThemeSource 的 工作 ， 最 后 使 用 主题 获取 里 面具 体 的 资源 就 可 以 了 。ThemeResolver 上 默认 使 用 的 是 FixedThemeResolver，ThemeSource 默 认 使 用 的 是 WebApplicationContext (其 实 


是 AbstractRefreshableWebApplicationContext 里 的 ThemeSource) ， 不 过 我 们 也 可 以 自己 来 配置 ， 例 如 : 


<bean id="themeSource" class="org.springframework.ui.context.support.ResourceBundleThemeSource" 


Pp:basenamePrefix="com.excelib.themes."/> 


<bean id="themeResolver" class="org.springframework.web.servlet.theme. CookieThemeResolver" 


p:defaultThemeName="default"/> 


这 里 不 仅 配 置 了 themeResolver 和 themeSource， 而 且 还 配置 了 默认 主题 名 为 “default”， 以 及 配置 文件 的 位 置 在 com.excelib.themes 包 下 (注意 配置 时 最 后 要 有 点 “.”) 。 


我 们 把 主题 是 怎么 回 事 就 讲 完了 ， 下 面 再 讲 一 下 怎么 切换 主题 ， 如 果 主 题 不 能 切换 就 失去 了 主题 的 意义 ， 所 以 主题 的 切换 非常 重要 。Spring MVC 中 主题 的 切换 和 Locale 的 切换 使 用 相同 的 模式 ， 也 是 


使 用 的 Interceptor。 配 置 如 下 : 


<mvc:interceptors> 
<mvce:interceptor> 
<mvc:mapping path="/*" /> 


<bean class="org.springframework.web.servlet.theme.ThemeChangeInterceptor" 


p:paramName="theme"/> 
</mvc:interceptor> 
</mvc:interceptors> 


可 以 通过 paramName 设 置 修改 主题 的 参数 名 ， 默 认 使 用 “theme”。 下 面 的 请 求 可 以 切换 为 summer 主 题 : 


http://localhost:8080?theme=summer 


11.8 MultipartResolver 


MultipartResolver 用 于 处 理 上 传 请 求 ， 处 理 方法 是 将 普通 的 request 包 装 成 Multipart-HttpServletRequest， 后 者 可 以 直接 调用 getFile 方 法 获取 到 File， 如 果 上 传 多 个 文件 ， 还 可 以 调用 getFileMap 得 
到 FileName 一 File 结 构 的 Map， 这 样 就 使 得 上 传 请 求 的 处 理 变 得 非常 简单 。 当 然 ， 这 里 做 的 其 实 是 锦上添花 的 事情 ， 如 果 上 传 的 请 求 不 用 MultipartResolver 封 装 成 MultipartHttpServletRequest， 直 接 
原来 的 request 也 是 可 以 的 ， 所 以 在 Spring MVC 中 此 组 件 没有 提供 默认 值 。MultipartResolver 定 义 如 下 : 


package org.springframework.web.multipart; 

import javax.servlet.http.HttpServletRequest; 

public interface MultipartResolver { 
boolean isMultipart (HttpServletRequest request); 
MultipartHttpServletRequest resolveMultipart (HttpServletRequest request) throws MultipartException; 
void cleanupMultipart (MultipartHttpServletRequest request); 

} 


这 里 一 共有 三 个 方法 ， 作 用 分 别 是 判断 是 不 是 上 传 请 求 、 将 request 包 装 成 Multipart-HttpServletRequest、 处 理 完 后 清理 上 传 过 程 中 产生 的 临时 资源 。 对 上 传 请 求 可 以 简单 地 判断 是 不 是 
multipart/form-data 类 型 ， 更 多 详细 内 容 后 面 再 介绍 。 


11.9 FlashMapManager 


FlashMap 相 关 的 内 容 在 前 面 已 经 介绍 过 了 ， 主 


在 redirect 中 传递 参数 。 而 FlashMap-Manager 是 用 来 管理 FlashMap 的 ， 定 义 如 下 : 


Package org.springframework.web.servlet; 
import javax.servlet.http.HttpServletRequest; 
import javax.servlet.http.HttpServletResponse; 
public interface FlashMapManager { 
FlashMap retrieveAndUpdate (HttpServletRequest request, HttpServletResponse response); 


void saveOutputFlashMap (FlashMap flashMap, HttpServletRequest request, HttpServletResponse response); 
} 


retrieveAndUpdate 方 法 用 于 恢复 参数 ， 并 将 恢复 过 的 和 超时 的 参数 从 保存 介质 中 删除 ; saveOutputFlashMap 用 于 将 参数 保存 起 来 。 


默认 实现 是 org.springframework.web.servlet.support.SessionFlashMapManager， 它 是 将 参数 保存 到 session 中 。 


整个 redirect 的 参数 通过 FlashMap 传 递 的 过 程 分 三 步 : 


1) 在 处 理 器 中 将 需要 传递 的 参数 设置 到 outputFlashMap 中 ， 设 置 方法 在 分 析 Dispat-cherServlet 的 时 候 已 经 介绍 了 ， 可 以 直接 使 


request.getAttribute- (DispatcherServlet.OUTPUT_FLASH_MAP_ATTRIBUTE) 拿 到 outputFlashMap， 然 后 将 参数 put 进 去 ， 也 可 以 将 需要 传递 的 参数 设置 到 处 理 器 的 RedirectAttributes 类 型 的 参数 
中 ， 当 处 理 器 处 理 完 请 求 时 ， 如 果 是 redirect 类 型 的 返回 值 RequestMappingHandlerAdapter 会 将 其 设置 到 outputFlashMap 中 。 


2) 在 RedirectView 的 renderMergedOutputMode| 方 法 中 调用 FlashMapManager 的 saveOutput-FlashMap 方 法 ， 将 outputFlashMap 中 的 参数 设置 到 Session 中 。 


3) 请 求 redirect 后 DispatcherServlet 的 doServic 会 调用 FlashMapManager 的 retrieveAnd-Update 方 法 从 Session 中 获取 inputFlashMap 并 设置 到 Request 的 属性 中 备用 ， 同 时 从 session 中 删除 。 


11.10 小 结 


本 章 对 Spring MVC 中 的 九 大 组 件 从 接口 、 作 用 、 原 理 、 用 法 等 方面 进行 了 介绍 ， 学 习 了 本 章 大 家 再 回 过 头 去 看 doDispatcher 就 会 有 更 加 深刻 的 理解 。 同 时 也 为 后 面 详细 分 析 每 个 组 件 的 具体 实现 奠定 
了 基础 。 


到 目前 为 止 ， 大 家 对 Spring MVC 内 部 的 机 制 已 经 有 了 全 面 的 认识 ， 即 使 不 再 往 下 看 也 已 明白 Spring MVC 到 底 是 怎么 回 事 了 ， 不 过 如 果 想 更 深入 地 了 解 每 个 组 件 背 后 的 实现 原理 则 还 需要 接着 往 下 看 。 


第 12 章 HandlerMapping 


HandlerMapping 的 继承 结构 如 图 12-1 所 示 。 


1 HandlerMapping 


© AbstractHandlerMapping 
人 


C AbstractHandlerMethodMapping CAbstractUrlHandlerMapping 


[c RequestMappingInfoHandlerMapping| 


C AbstractDetecingUrlHandlerMapping © SimpleUrlHandlerMapping| 


人 人 


© DefaultAnnotationHandlerMapping | ”|@BeanNameUdHandlerMapping| 


Ic RequestMappingHandlerMapping 


C AbstractControolUrlHandlerMapping 
C ControolerClassNameHandlerMapping 


C ControolerBeanNameHandlerMapping 


图 12-1 HandlerMapping 继 承 结构 图 


可 以 看 到 HandlerMapping 家 族 的 成 员 可 以 分 为 两 支 ， 一 支 继承 AbstractUrlHandlerMapping， 另 一 支 继 承 AbstractHandlerMethodMapping， 而 这 两 个 支 都 继承 自 抽象 类 


AbstractHandlerMapping。 所 以 本 章 首先 分 析 AbstractHandlerMapping， 然 后 分 别 分 析 AbstractUrlHandlerMapping 和 AbstractHandlerMethodMapping 两 个 系列 ， 最 后 总 结 ， 分 析 的 方法 使 用 “器 


分 析 法 ”。 


12.1 AbstractHandlerMapping 


体 结构 ， 子 类 只 需要 通过 模板 方法 提供 一 些 初始 值 或 者 具体 的 算法 即 可 。 将 AbstractHa-ndlerMapping 分 析 透 对 整个 HandlerMapping 实 现 方式 的 理解 至 关 


AbstractHandlerMapping 是 HandlerMapping 的 抽象 实现 ， 所 有 HandlerMapping 都 继承 自 AbstractHandlerMapping。AbstractHandlerMapping 采 用 模板 模式 设计 了 HandlerMapping 实 现 的 整 
。 在 Spring MVC 中 有 很 多 组 件 都 是 采用 的 


这 种 模式 一 一 首先 使 用 一 个 抽象 实现 采用 模板 模式 进行 整体 设计 ， 然 后 在 子 类 通过 实现 模板 方法 具体 完成 业务 ， 所 以 在 分 析 Spring MVC 源 码 的 过 程 中 尤其 要 重视 对 组 件 接口 直接 实现 的 抽象 实现 类 的 分 


析 。 


HandlerMapping 的 作用 是 根据 request 查 找 Handler 和 Interceptors。 获 取 Handler 的 过 程 通过 模板 方法 getHandlerlnternal 交 给 了 子 类 。AbstractHandlerMapping 中 保存 了 所 用 配置 的 


Interceptor， 在 获取 到 Handler 后 会 自己 根据 从 request 提 取 的 lookupPath 将 相应 的 Inte-rceptors 装 配 上 去 ， 当 然 子 类 也 可 以 通过 getHandlerlnterna| 方 法 设置 自己 的 Interceptor，getHandlerlnternal 的 
返回 值 为 Object 类 型 。 
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.1.1 创建 AbstractHandlerMapping 之 器 


AbstractHandlerMapping 继 承 了 WebApplicationObjectSupport， 初 始 化 时 会 自动 调 


模板 方法 initApplicationContext，AbstractHandlerMapping 的 创建 就 是 在 initApplicationContext 方 法 里 


面 实现 的 ， 代 码 如 下 : 


//org.springframework.web.servlet .handler.AbstractHandlerMapping 

protected void initApplicationContext() throws BeansException { 
extendInterceptors (this.interceptors); 
detectMappedInterceptors (this.mappedInterceptors); 
initInterceptors (); 


initApplicationContext 里 一 共有 三 个 方法 ， 我 们 分 别 来 说 一 下 。 


extendinterceptors 是 模板 方法 ， 用 于 给 子 类 提供 一 个 添加 (或 者 修改 ) Interceptors 的 入 口 ， 不 过 在 现 有 Spring MVC 的 实现 中 并 没有 使 用 。 


detectMappedlnterceptors 方 法 用 于 将 Spring MVC 容 器 及 父 容器 中 的 所 有 Mappedlnter-ceptor 类 型 的 Bean 添 加 到 mappedlnterceptors 属 性 ， 代 码 如 下 : 


//org.spPringframework.web.servlet.handler.AbstractHandlerMapping 
protected void detectMappedInterceptors (List<MappedInterceptor> mappedInterceptors) { 
mappedInterceptors.addAll ( 
BeanFactoryUtils.beansOfTypeIncludingAncestors( 
getApplicationContext (), MappedInterceptor.class, true, false) .values()); 


initInterceptors 方 法 的 作用 是 初始 化 Interceptor， 有 具体 内 容 其 实 是 将 interceptors 属 性 里 所 包含 的 对 象 按 类 型 添加 到 mappedlnterceptors 或 者 adaptedlnterceptors， 代 码 如 下 : 


//org.sPringframework.web.servlet.handler.AbstractHandlerMapping 
protected void initInterceptors () { 
if (!this.interceptors.isEmpty()) { 


for (int i = 0; i < this.interceptors.size(); i++) { 
Object interceptor = this.interceptors.get (i); 
if (interceptor == null) { 


throw new IllegalArgumentException("Entry number " + i + " in interceptors array is null"); 
} 
if (interceptor instanceof MappedInterceptor) { 
this.mappedInterceptors.add ( (MappedInterceptor) interceptor); 
jelse { 
this.adaptedIinterceptors.add (adaptInterceptor (interceptor)); 
i 


AbstractHandlerMapping 中 的 Interceptor 有 三 个 List 类 型 的 属性 : interceptors、mapped-Interceptors 和 adaptedinterceptors， 分 别 解释 如 下 : 


“ Interceptors: 用 于 配置 SpringMVC 的 拦截 器 ， 有 两 种 设置 方式 : 四 注册 HandlerMapping 时 通过 属性 设置 ; @ 通 过 子 类 的 extendInterceptots 钧 子 方法 进行 设置 。Interceptors 并 不 会 直接 使 用 ， 而 是 通过 


initInterceptors 方 法 按 类 型 分 配 到 mapped-Interceptors 和 adaptedInterceptors 中 进行 使 用 ，Interceptors 只 用 于 配置 。 


“ mappedInterceptors: 此 类 Interceptot 在 使 用 时 需要 与 请 求 的 ul 进行 匹配 ， 只 有 匹配 成 功 后 才 会 添加 到 getHandlet 的 返回 值 HandlerExecutionChain 里 。 它 有 两 种 获取 途径 : 从 interceptors 获 取 或 者 注册 到 


spring 的 容器 中 通过 detectMappedInterceptors 方 法 获取 。 


T2: 


“ adaptedInterceptors: 这 种 类 型 的 Interceptor 不 需要 进行 匹配 ， 在 getHandler 中 会 全 部 添加 到 返回 值 HandlerExecutionChain 里 面 。 它 只 能 从 interceptors 中 获取 。 


AbstractHandlerMapping 的 创建 其 实 就 是 初始 化 这 三 个 Interceptor。 


1.2 AbstractHandlerMapping 之 用 


HandlerMapping 是 通过 getHandler 方 法 来 获取 处 理 器 Handler 和 拦截 器 Interceptor 的 ， 下 面 看 一 下 在 AbstractHandlerMapping 中 的 实现 方法 。 


//org.springframework.web.servlet.handler.AbstractHandlerMapping 
public final HandlerExecutionChain getHandler (HttpServletRequest request) throws Exception { 
Object handler = getHandlerInternal (request); 
if (handler == null) { 
handler = getDefaultHandler () 7 


} 
if (handler == null) { 
return null; 
} 
// Bean name or resolved handler? 
if (handler instanceof String) { 
String handlerName = (String) handler; 
handler = getApplicationContext () .getBean (handlerName); 
} 


return getHandlerExecutionChain (handler, request); 


可 以 看 到 getHandler 方 法 的 实现 共 分 两 部 分 ，getHandlerExecutionChain 之 前 是 找 Handl-er，getHandlerExecutionChain 方 法 用 于 添加 拦截 器 。 


找 Handler 的 过 程 是 这 样 的 : 


1) 通过 getHandlerlnternal (request) 方法 获取 ， 这 是 个 模板 方法 ， 留 给 子 类 具体 实现 (这 也 是 其 子 类 主要 做 的 事情 ) 。 


2) 如 果 没 有 获取 到 则 使 用 默认 的 Handler， 默 认 的 Handler 保 存在 AbstractHandler-Mapping 的 一 个 Object 类 型 的 属性 defaultHandler 中 ， 可 以 在 配置 HandlerMapping 时 进行 配置 ， 也 可 以 在 子 类 
中 进行 设置 。 


3) 如 果 找 到 的 Handler 是 String 类 型 ， 则 以 它 为 名 到 Spring MVC 的 容器 里 查找 相应 的 Bean。 


下 面 再 来 看 一 下 getHandlerExecutionChain 方 法 。 


//org.sPringframework.web.servlet.handler.AbstractHandlerMapping 
protected HandlerExecutionChain getHandlerExecutionChain (Object handler, HttpServletRequest request) { 
HandlerExecutionChain chain = (handler instanceof HandlerExecutionChain ? 
(HandlerExecutionChain) handler : new HandlerExecutionChain (handler)); 
chain.addIinterceptors (getAdaptedInterceptors () ) 7 
String lookupPath = this.urlPathHelper.getLookupPathForRequest (request) 
for (MappedIinterceptor mappedIinterceptor : this.mappedInterceptors) { 
if (mappedInterceptor.matches (lookupPath, this.pathMatcher)) { 
chain.addInterceptor (mappedInterceptor .getInterceptor ()); 
} 
} 


return chain; 


这 个 方法 也 非常 简单 ， 首 先 使 用 handler 创 建 出 HandlerExecutionChain 类 型 的 变量 ， 然 后 将 adaptedlnterceptors 和 符合 要 求 的 mappedlnterceptors 添 加 进去 ， 最 后 将 其 返回 。 


12.2 ”AbstractUrlHandlerMapping 系 列 


12.2.1 AbstractUrlHandlerMapping 


AbstractUrlHandlerMapping 系 列 都 继承 自 AbstractUrlHandlerMapping， 从 名 字 就 可 以 看 出 它 是 通过 url 来 进行 匹配 的 。 此 系列 大 致 原理 是 将 ur 与 对 应 的 Handler 保 存在 一 个 Map 中 ,在 
getHandlerlnternal 方 法 中 使 用 url 从 Map 中 获取 Handler，AbstractUrlHandlerMapping 中 实现 了 有 具体 用 url 从 Map 中 获取 Handler 的 过 程 ， 而 Map 的 初始 化 则 交 给 了 有 具体 的 子孙 类 去 完成 。 这 里 的 Map 就 
是 定义 在 AbstractUrlHandlerMapping 中 的 handlerMap， 另 外 还 单独 定义 了 处 理 “/” 请 求 的 处 理 器 rootHandler， 定 义 如 下 : 


//org.springframework.web.servlet.handler.AbstractUrlHandlerMapping 
private Object rootHandler; 
private final Map<String, Object> handlerMap = new LinkedHashMap<String, Object>(); 


下 面 看 一 下 具体 是 怎么 获取 Handler 的 ， 以 及 这 个 Map 是 怎么 创建 的 。 


前 面 讲 过 获取 Handler 的 入 口 是 getHandlerlnterna| 方 法 ， 它 在 AbstractUrlHandlerMapp-ing 中 代码 如 下 : 


//org.springframework.web.servlet.handler.AbstractUrlHandlerMapping 
protected Object getHandlerInternal (HttpServletRequest request) throws Exception { 
String lookupPath = getUrlPathHelper () .getLookupPathForRequest (request); 
Object handler = lookupHandler (lookupPath, request); 
if (handler == null) { 
// 定义 一 个 临时 变量 ,保存 找到 的 原始 Handler 
Object rawHandler = null; 
if ("/".equals(lookupPath)) { 
rawHandler = getRootHandler (); 
} 
if (rawHandler == null) { 
rawHandler = getDefaultHandler (); 


if (rawHandler != null) { 
// 如 果 是 String 类 型 则 到 容器 中 查找 具体 的 Bean 
if (rawHandler instanceof String) { 
String handlerName = (String) rawHandler; 
rawHandler = getApplicationContext () .getBean (handlerName); 


} 
// 可 以 用 来 校 验 找到 的 Handler 和 request 是 否 匹 配 ， 是 模板 方法 ， 而 且 子 类 也 没有 使 用 
validateHandler (rawHandler, request); 
handler = buildPathExposingHandler (rawHandler, lookupPath, lookupPath, null); 
} 
} 
if (handler != null && logger.isDebugEnabled()) { 
logger.debug ("Mapping [" + lookupPath + "] to " + handler); 
jelse if (handler 一 null && logger.isTraceEnabled()) { 
logger.trace ("No handler mapping found for [" + lookupPath + "™]"); 


return handler; 


这 里 除了 lookupHandler 和 buildPathExposingHandler 方 法 外 都 非常 容易 理解 ， 我 们 就 不 多 解释 了 。 下 面 分 别 来 分 析 这 两 个 方法 。 


lookupHandler 方 法 上 


于 使 用 lookupPath 从 Map 中 查找 Handler， 不 过 很 多 时 候 并 不 能 直接 从 Map 中 get 到 ， 因 为 很 多 Handler 都 是 用 了 Pattern 的 匹配 模式 ， 如 “/showy/article/*” ， 这 里 的 星 号 * 可 
以 代表 任意 内 容 而 不 是 真正 匹配 url 中 的 星 号 ， 如 果 Pattern 中 包含 PathVariable 也 不 能 直接 从 Map 中 获取 到 。 另 外 ， 一 个 url 还 可 能 跟 多 个 Pattern 相 匹配 ， 这 时 还 需要 选择 其 中 最 优 的 ， 所 以 查找 过 程 其 实 
并 不 是 直接 简单 地 从 Map 里 获取 ， 单 独 写 一 个 方法 来 做 也 是 应 该 的 。lookupHandler 的 代码 如 下 : 


//org.spPringframework.web.servlet.handler.AbstractUr1HandlerMappPing 
protected Object lookupHandler (String urlPath, HttpServletRequest request) throws Exception { 
// 直接 从 Map 中 获取 
Object handler = this.handlerMap.get (urlPath); 
if (handler != null) { 
// 如 果 是 String 类 型 则 从 容器 中 获取 
if (handler instanceof String) { 
String handlerName = (String) handler; 
handler = getApplicationContext () .getBean (handlerName); 


} 
validateHandler (handler, request); 
return buildPathExposingHandler (handler, urlPath, urlPath, null); 


t 
// Pattern 匹 配 ， 比 如 使 用 带 * 号 的 模式 与 url 进行 匹配 
List<String> matchingPatterns = new ArrayList<String>(); 
for (String registeredPattern : this.handlerMap.keySet()) { 
if (getPathMatcher() .match (registeredPattern, urlPath)) { 
matchingPatterns.add (registeredPattern); 
} 


String bestPatternMatch = null; 
Comparator<String> patternComparator = getPathMatcher () .getPatternComparator (urlPath); 


if 


} 
4 


(!matchingPatterns .isEmpty()) { 
Collections .sort (matchingPatterns, patternComparator); 
if (logger.isDebugEnabled()) { 
logger.debug ("Matching patterns for request [" + urlPath + "] are " + matcl 


bestPatternMatch = matchingPatterns.get (0); 


(bestPatternMatch != null) { 
handler = this.handlerMap.get (bestPatternMatch); 
// 如 果 是 String 类 型 则 从 容器 中 获取 
if (handler instanceof String) { 
String handlerName = (String) handler; 
handler = getApplicationContext () .getBean (handlerName); 
} 
validateHandler (handler, request); 
String pathWithinMapping = getPathMatcher () .extractPathWithinPattern (bestPatter 


hingPatterns); 


nMatch, urlPath); 


// 之 前 是 通过 sort 方 法 进行 排序 ， 然 后 拿 第 一 个 作为 bestPatternMatch 的 ， 不 过 有 可 能 有 多 个 Pattern 的 顺序 相同 ， 也 就 是 sort 方 法 返回 0， 这 里 就 是 处 理 这 种 情况 


Map<String, String> uriTemplateVariables = new LinkedHashMap<String, String>(); 
for (String matchingPattern : matchingPatterns) { 
if (patternComparator.compare (bestPatternMatch, matchingPattern) == 0) { 
Map<String, String> vars = getPathMatcher () .extractUriTemplateVariables (mat 
Map<String, String> decodedVars = getUrlPathHelper () .decodePathVariable. 
uriTemplateVariables .putAll] (decodedVars); 
$ 
} 
if (logger.isDebugEnabled()) { 


chingPattern, urlPath); 
s (request, vars); 


logger.debug ("URI Template variables for request [" + urlPath + "] are " + uriTemplateVariables); 


return buildPathExposingHandler (handler, bestPatternMatch, pathWithinMapping, u: 


} 
// 没 找 到 Handler 则 返回 null 
return null; 


riTemplateVariables); 


关键 位 置 已 经 做 了 注释 ， 在 此 就 不 解释 了 。 可 以 看 到 查找 Handler 的 关键 还 是 保存 url 和 Handler 的 那个 Map， 后 面 会 分 析 这 个 Map 是 怎么 初始 化 的 。 


buildPathExposingHandler 方 法 
前 url 实 际 匹 配 的 Pattern、 匹 配 条 件 (后 面 介绍 ) 和 url 模 板 参数 等 设置 到 request 的 


于 给 查找 到 的 Handler 注 册 两 个 拦截 器 PathExposing-Handlerlnterceptor 和 UriTemplateVariablesHandlerlnterceptor， 这 是 两 个 内 部 拦截 器 ， 主 要 作用 是 将 与 当 


属性 里 ， 这 样 在 后 面 的 处 理 过 程 中 就 可 以 直接 从 request 属 性 中 获取 ， 而 不 需 


新 查找 一 遍 了 ， 代 码 如 下 : 


//org.spPringframework.web.servlet.handler.AbstractUr1HandlerMapPing 
protected Object buildPathExposingHandler (Object rawHandler, String bestMatchingPattern, 
String pathWithinMapping, Map<String, String> uriTemplateVariables) { 
HandlerExecutionChain chain = new HandlerExecutionChain (rawHandler); 
chain.addIinterceptor (new PathExposingHandlerInterceptor (bestMatchingPattern, pathWithinMapping)); 
if (!CollectionUtils.isEmpty (uriTemplateVariables)) { 
chain.addIinterceptor (new UriTemplateVariablesHandlerInterceptor (uriTemplateVariables)); 


l 


return chain; 


private class PathExposingHandlerIinterceptor extends HandlerIinterceptorAdapter { 
Private final String bestMatchingPattern; 
Private final String pathWithinMapping; 
public PathExposingHandlerInterceptor (String bestMatchingPattern, String pathWithinMapping) { 
this.bestMatchingPattern = bestMatchingPattern; 
this.pathWwithinMapping = pathWithinMapping; 


’ 


@Override 
public boolean preHandle (HttpServletRequest request, HttpServletResponse response, Object handler) { 
exposePathWithinMapping (this.bestMatchingPattern, this.pathWithinMapping, request); 
request .setAttribute (HandlerMapping.INTROSPECT_TYPE LEVEL MAPPING, supportsTypeLevelMappings()); 
return true; 


} 


} 

protected void exposePathWithinMapping (String bestMatchingPattern, String pathWithinMapping, HttpServletRequest request) { 
request .setAttribute (HandlerMapping.BEST MATCHING PATTERN ATTRIBUTE, bestMatchingPattern); 
request .setAttribute (HandlerMapping.PATH WITHIN HANDLER MAPPING ATTRIBUTE, pathWithinMapping); 


private class UriTemplateVariablesHandlerInterceptor extends HandlerInterceptorAdapter { 
private final Map<String, String> uriTemplateVariables; 

public UriTemplateVariablesHandlerIinterceptor (Map<String, String> uriTemplateVariables) { 

this.uriTemplateVariables = uriTemplateVariables; 


于 


@Override 

public boolean preHandle (HttpServletRequest request, HttpServletResponse response, Object handler) { 
exposeUriTemplateVariables (this.uriTemplateVariables, request); 
Yeturn Yue 


} 


} 
protected void exposeUriTemplateVariables (Map<String, String> uriTemplateVariables, HttpServletRequest request) { 
request .setAttribute (HandlerMapping.URI TEMPLATE VARIABLES ATTRIBUTE, uriTemplateVariables); 


} 


在 buildPathExposingHandler 方 法 中 给 Handler 注 册 两 个 内 部 拦截 器 PathExposingHandler-Interceptor 和 UriTemplateVariablesHandlerlnterceptor， 这 两 个 拦截 器 分 别 在 preHandle 中 调用 了 


exposePathWithinMapping 和 exposeUriTemplateVariables 方 法 将 相应 内 容 设置 到 了 request 的 属性 。 


下 面 介 绍 Map 的 初始 化 ， 它 通过 registerHandler 方 法 进行 ， 这 个 方法 承担 AbstractUrlHandler-Mapping 的 创建 工作 ， 不 过 和 之 前 的 创建 不 同 的 是 这 里 的 registerHandler 方 法 并 不 是 自己 调用 ， 也 不 是 


父 类 调用 ， 而 是 子 类 调用 。 这 样 不 同 的 子 类 就 可 以 通过 注册 不 同 的 Handler 将 组 件 创 建 出 来 。 这 种 思路 也 值得 我 们 学 习 和 借鉴 。 


AbstractUrlHandlerMapping 中 有 两 个 registerHandler 方 法 ， 第 一 个 方法 可 以 注册 多 个 url 到 一 个 处 理 器 ， 处 理 器 用 的 是 String 类 型 的 beanName， 这 种 用 法 在 前 面 已 经 多 次 见 到 过 ， 它 可 以 使 
beanName 到 spring 的 容器 里 找到 真实 的 bean 做 处 理 器 。 在 这 个 方法 里 只 是 遍历 了 所 有 的 url， 然 后 调 


第 二 个 registerHandler 方 法 具体 将 Handler 注 册 到 Map 上 。 第 二 个 registerHandler 方 法 的 具体 注册 


过 程 也 非常 简单 ， 首 先 看 Map 里 原来 有 没有 传 入 的 url， 如 果 没 有 就 put 进 去 ， 如 果 有 就 看 一 下 原来 保存 
的 Handler 吧 (这 个 系列 只 根 所 


defaultHandler。 具 体 代 码 如 下 : 


的 和 现在 要 注册 的 Handler 是 不 是 同一 个 ， 如 果 不 是 同一 个 就 有 问题 了 ， 总 不 能 相同 的 url 有 两 个 不 同 


居 url 查 找 Handler) ! 这 时 就 得 抛 异常 。 往 Map 里 放 的 时 候 还 需要 看 一 下 url 是 不 是 处 理 “/” 或者“/*” ， 如 果 是 就 不 往 Map 里 放 了 ， 而 是 分 别 设置 到 rootHandler 和 


//org.springframework.web.servlet .handler.AbstractUrlHandlerMapping 

protected void registerHandler (String[] urlPaths, String beanName) throws BeansException, IllegalStateException { 
Assert .notNull (urlPaths, "URL path array must not be null"); 
for (String urlPath : urlPaths) { 


} 


registerHandler (urlPath, beanName); 


protected void registerHandler (String urlPath, Object handler) throws BeansException, IllegalStateException { 
Assert .notNull (urlPath, "URL path must not be null"); 
Assert .notNull (handler, "Handler object must not be null"); 
Object resolvedHandler = handler; 
// 如 果 Handler 是 String 类 型 而 且 没 有 设置 lazyInitHandlers 则 从 SpringMVC 容 器 中 获取 Handler 
if (!this.lazyInitHandlers && handler instanceof String) { 


} 


String handlerName = (String) handler; 

if (getApplicationContext() .isSingleton (handlerName)) { 
resolvedHandler = getApplicationContext () .getBean (handlerName); 

} 


Object mappedHandler = this.handlerMap.get (urlPath); 
if (mappedHandler != null) { 


if (mappedHandler != resolvedHandler) { 
throw new IllegalStateException( 


"Cannot map " + getHandlerDescription (handler) + " to URL path [" + urlPath + 
"]: There is already " + getHandlerDescription (mappedHandler) + " mapped."); 


}else { 
if (urlPath.equals("/")) { 
if (logger.isInfoPnabledq()) { 
Jogger .info ("Root mapping to " + getHandlerDescription (handler)); 


setRootHandler (resolvedHandler); 
lelse if (urlPath.equals("/*")) { 
if (logger.isInfoEnabled()) { 
logger.info("Default mapping to " + getHandlerDescription (handler) ) 7 


} 
setDefaultHandler (resolvedHandler); 
jelse { 
this.handlerMap.put (urlPath, resolvedHandler); 
if (logger.isInfoEnabled()) { 


logger.info ("Mapped URL path [" + urlPath + "] onto " + getHandlerDescription (handler)); 


’ 


我 们 现在 就 把 整个 AbstractUrlHandlerMapping 系 列 的 原理 分 析 完 了 ，AbstractUrl-Handler-Mapping 里 面 定义 了 整体 架构 ， 子 类 只 需要 将 Map 初 始 化 就 可 以 了 。 


12.2.2 SimpleUrlHandlerMapping 


SimpleUrlHandlerMapping 定 义 了 一 个 Map 变 量 (自己 定义 一 个 Map3 


下 面 来 看 子 类 具体 是 怎么 做 的 。 有 两 个 类 直接 继承 AbstractUrlHandlerMapping， 分 别 是 SimpleUrlHandlerMapping 和 AbstractDetectingUrlHandlerMapping。 


上 要 有 两 个 作用 ， 第 一 是 方便 配置 ， 第 二 是 可 以 在 注册 前 做 一 些 预 处 理 ， 如 确保 所 有 url 都 以 “/” 开 头 ) ， 将 所 有 的 url 和 


Handler 的 对 应 关系 放 在 里 面 ， 最 后 注册 到 父 类 的 Map 中 ; 而 AbstractDetectingUrlHandlerMapping 则 是 将 容器 中 的 所 有 bean 都 拿 出 来 ， 按 一 定 规则 注册 到 父 类 的 Map 中 。 下 面 分 别 来 看 一 下 。 


SimpleUrlHandlerMapping 在 创建 时 通过 


父 类 的 initApplicationContext 方 法 调用 了 registerHandlers 方 法 完成 Handler 的 注册 ，registerHandlers 内 部 又 调用 了 Abstract-UrlHandlerMapping 的 


registerHandler 方 法 将 我 们 配置 的 urIMap 注 册 到 AbstractUrlHandler-Mapping 的 Map 中 (如果 要 使 用 SimpleUrlHandlerMapping 就 需要 在 注册 时 给 它 配置 urIMap) ， 代 码 如 下 : 


//org.springframework.web.servlet .handler.SimpleUrlHandlerMapping 
private final Map<String, Object> urlMap = new HashMap<String, Object>() 
Public void initApplicationContext () throws BeansException { 
super.initApplicationContext () 7 
registerHandlers (this.urlMap); 
} 
protected void registerHandlers (Map<String, Object> urlMap) throws BeansException { 
if (urlMap.isEmpty()) { 
logger.warn ("Neither 'urlMap' nor 'mappings' set on SimpleUrlHandlerMapping"); 
}else { 
for (Map.Entry<String, Object> entry : urlMap.entrySet()) { 
String Url = entry.getKey(); 
Object handler = entry.getValue(); 
// Prepend with slash if not already present. 
if (lurl.startsWith("/")) { 
url = "/" + url; 
} 
// Remove whitespace from handler bean name. 
if (handler instanceof String) { 
handler = ((String) handler) .trim(); 
} 


registerHandler (url, handler); 


SimpleUrlHandlerMapping 类 非常 简单 ， 就 是 直接 将 配置 的 内 容 注册 到 了 AbstractUrlHa-ndlerMapping 中 。 


12.2.3 AbstractDetectingUrlHandlerMapping 


AbstractDetectingUrlHandlerMapping 也 是 通过 重 写 initApplicationContext 来 注册 Handler 的 ,里 


回 


调用 了 detectHandlers 方 法 ， 在 detectHandlers 中 根据 配置 的 detectHand-lerslnAn- 


cestorContexts 参 数 从 Spring MVC 容 器 或 者 Spring MVC 及 其 父 容器 中 找到 所 有 bean 的 beanName， 然 后 用 determineUrlsForHandler 方 法 对 每 个 beanName 解 析出 对 应 的 urls， 如 果 解 析 结 果 不 为 空 则 
将 解析 出 的 urls 和 beanName (作为 Handler) 注册 到 父 类 的 Map， 注 册 方 法 依然 是 调用 AbstractUrlHandlerMapping 的 registerHandler 方 法 。 使 用 beanName 解 析 urls 的 determineUrlsForHandler 方 法 


是 模板 方法 ， 交 给 具体 子 类 实现 。AbstractDetectingUrlHandlerMapping 类 非常 简单 ， 代 码 如 下 : 


Package org.springframework.web.servlet.handler; 
public abstract class AbstractDetectingUrlHandlerMapping extends AbstractUrlHandlerMapping { 
Private boolean detectHandlersIinAncestorContexts = false; 
public void setDetectHandlersInAncestorContexts (boolean detectHandlersInAncestorContexts) { 
this.detectHandlersInAncestorContexts = detectHandlersIinAncestorContexts; 
} 
QOverride 
public void initApplicationContext () throws ApplicationContextException { 
super.initApplicationContext (); 
detectHandlers () 7 
} 
protected void detectHandlers () throws BeansException { 
if (logger.isDebugEnabled()) { 
logger.debug ("Looking for URL mappings in application context: " + getApplicationContext ()); 


} 
// 获 取 容 器 的 所 有 bean 的 名 字 
String[] beanNames = (this.detectHandlersInAncestorContexts ? 
BeanFactoryUti1s .beanNamesForTypeIncludingaAncestors (getApplicationContext (), Object.class) 
getApplicationContext () .getBeanNamesForType (Object .class)); 
// 对 每 个 beanName 解 析 url， 如 果 能 解析 到 就 注册 到 父 类 的 Map 中 
for (String beanName : beanNames) { 
// 使 用 peanName 解 析 url， 是 模板 方法 ， 子 类 具体 实现 
String[] urls = determineUrlsForHandler (beanName); 
// 如 果 能 解析 到 url 则 注册 到 父 类 
if (!ObjectUtils.isEmpty(urls)) { 
// 父 类 的 registerHandler 方 法 
registerHandler (urls, beanName); 
}else { 
if (logger.isDebugEnabled()) { 
logger.debug ("Rejected bean name '" + beanName + "': no URL paths identified"); 
} 


} 
} 


protected abstract String[] determineUrlsForHandler (String beanName); 


AbstractDetectingUrlHandlerMapping 有 三 个 子 类 : BeanNameUrlHandlerMapping、Default-AnnotationHandlerMapping 和 AbstractControllerUrlHandlerMapping， 其 中 


DefaultAnnotation-HandlerMapping 已 经 标注 了 @ Deprecated 被 弃 用 了 ， 所 以 我 们 就 不 分 析 它 了 。 


BeanNameUrlHandlerMapping 是 检查 beanName 和 alias 是 不 是 以 “/” 开 头 ， 如 果 是 则 将 其 作为 url， 里 面 只 有 一 个 determineUrlsForHandler 方 法 ， 非 常 简单 ， 代 码 如 下 : 


Package org.springframework.web.servlet.handler; 
// 上 省略 了 imports 


public class BeanNameUrlHandlerMapping extends AbstractDetectingUrlHandlerMapping { 
QOverride 
Protected String[] determineUrlsForHandler (String beanName) { 
List<String> urls = new ArrayList<String>(); 
if (beanName.startsWith("/")) { 
urls.add (beanName); 
} 
String[] aliases = getApplicationContext () .getAliases (beanName); 
for (String alias : aliases) { 
if (alias.startsWith("/")) { 
urls.add(alias); 
} 
} 
return StringUtils.toSstringArray (urls); 


AbstractControllerUrlHandlerMapping 是 将 实现 了 Controller 接 口 或 者 注释 了 @Controller 的 bean 作 为 Handler， 并 且 可 以 通过 设置 excludedClasses 和 excludedPackages 将 不 包含 的 bean 或 者 不 包 
含 的 包 下 的 所 有 bean 排 除 在 外 ， 这 里 的 determineUrlsForHandler 方 法 主要 负责 将 符合 条 件 的 Handler 找 出 来 ， 而 具体 用 什么 url 则 使 用 模板 方法 buildUrlsForHandler 交 给 子 类 去 做 ,代码 如 下 (省 略 了 打 
印 日 志 代码 ) : 


// org.springframework.web.servlet .mvce.support.AbstractControllerUrlHandlerMapping 
QOverride 
protected String[] determineUrlsForHandler (String beanName) { 
Class<?> beanClass = getApplicationContext () .getType (beanName); 
// 调用 isEligibleForMapping 方 法 判断 是 不 是 支持 的 类 型 
if (isEligibleForMapping (beanName, beanClass)) { 
// 模板 方法 ， 在 子 类 实现 
return buildUrlsForHandler (beanName, beanClass); 
ls 
else { 
return null; 


i 


protected boolean isEligibleForMapping (String beanName, Class<?> beanClass) { 
if (beanClass == null) { 
return false; 


} 

// 排 除 excludedClasses 里 配置 的 类 

if (this.excludedClasses.contains (beanClass)) { 
return false; 

} 

String beanClassName = beanClass.getName (); 

// 排 除 excludedPackages 里 配置 的 包 下 的 类 

for (String packageName : this.excludedPackages) { 
if (beanClassName.startsWith (packageName)) { 

return false; 

} 

} 

// 检查 是 否 实现 了 Controller 接 口 或 者 注释 了 @Controller 

return isControllerType (beanClass); 


protected abstract String[] buildUrlsForHandler (String beanName, Class<?> beanClass); 


它 有 两 个 子 类 ControllerClassNameHandlerMapping 和 ControllerBeanNameHandlerMapping， 从 名 称 就 可 以 看 出 来 一 个 使 用 className 作 为 url， 另 一 个 使 用 spring 容 器 中 的 beanName 作 为 
url， 具 体 代码 不 再 列 出 。 


AbstractUrlHandlerMapping 系 列 就 分 析 完 了 ， 层 次 非常 清晰 ， 我 们 来 回顾 一 下 : 首先 在 AbstractUrlHandlerMapping 中 设计 了 整体 的 结构 ， 并 完成 了 查找 Handler 的 具体 逻辑 ， 其 中 需要 用 到 一 个 保 
存 url 和 Handler 对 应 关系 的 Map， 这 个 Map 的 内 容 是 留 给 子 类 初始 化 的 ， 这 里 提供 了 注册 (也 就 是 初始 化 Map) 的 工具 方法 registerHandler。 初 始 化 Map 时 分 了 两 种 实现 方式 ， 一 种 是 通过 手工 在 配置 文 
件 里 注册 ， 另 一 种 是 在 spring 的 容器 里 面 找 ， 第 二 种 方式 需要 将 容器 里 的 bean 按 照 特定 的 需求 筛选 出 来 ， 并 和 解析 出 一 个 url， 所 以 又 根据 这 两 个 需求 增加 了 两 层 子 类 。 


回 


12.3 ”AbstractHandlerMethodMapping 系 列 


从 前 面 HandlerMapping 的 结构 图 可 以 看 出 ，AbstractHandlerMethodMapping 系 列 的 结构 非常 简单 ， 只 有 三 个 类 : AbstractHandlerMethodMapping、RequestMappinglnfoHandlerMapping 
和 RequestMappingHandlerMapping， 这 三 个 类 依次 继承 ，AbstractHandlerMethodMapping 直 接 继承 自 AbstractHandlerMapping。 虽 然 看 起 来 这 里 的 结构 要 比 UrlIHandlerMapping 简 单 很 多 ， 但 是 
并 没有 因为 类 结构 简单 而 降低 复杂 度 。 


AbstractHandlerMethodMapping 系 列 是 将 Method 作 为 Handler 来 使 用 的 ， 这 也 是 我 们 现在 用 得 最 多 的 一 种 Handler， 比 如 经 常 使 用 的 @RequestMapping 所 注释 的 方法 就 是 这 种 Handler， 它 专门 
有 一 个 类 型 一 一 HandlerMethod， 也 就 是 Method 类 型 的 Handler。 


这 个 系列 还 是 比较 复杂 的 ， 所 以 使 用 “器 用 分 析 法 ”进行 分 析 。 


12.3.1 创建 AbstractHandlerMethodMapping 系 列 之 器 


想 弄 明白 AbstractHandlerMethodMapping 系 列 ， 最 关键 的 是 要 先 弄 明白 AbstractHan-dlerMethodMapping 里 三 个 Map 的 含义 ， 它 们 定义 如 下 : 


//org.spPringframework.web.servlet.handler.AbstractHandlerMethodMapping 

Private final Map<T, HandlerMethod> handlerMethods = new LinkedHashMap<T, HandlerMethod>(); 

private final MultiValueMap<String，T> urlMap = new LinkedMultiValueMap<String, T>(); 

private final MultiValueMap<String, HandlerMethod> nameMap = new LinkedMultiValueMap<String, HandlerMethod>(); 


这 里 的 泛 型 1 来 自 于 AbstractHandlerMethodMapping 类 的 定义 ， 代 码 如 下 : 


public abstract class AbstractHandlerMethodMapping<T> extends RbstractHandlerMapping implements InitializingBean {.…. 
} 


泛 型 T 在 spring 官 方 的 解释 是 “The mapping for a HandlerMethod containing the conditions needed to match the handler method to incoming request” 也 就 是 用 来 代表 匹配 Handler 的 条 
件 专门 使 用 的 一 种 类 ， 这 里 的 条 件 就 不 只 是 url1 了 ， 还 可 以 有 很 多 其 他 条 件 ， 如 request 的 类 型 (Get、Post 等 ) 、 请 求 的 参数 、Header 等 都 可 以 作为 匹配 HandlerMethod 的 条 件 。 默 认 使 用 的 是 
RequestMappinglnfo， 从 RequestMappinglnfoHandlerMapping 的 定义 就 可 以 看 出 。 


public abstract class RequestMappingInfoHandlerMapping extends AbstractHandlerMethodMapping<RequestMappingInfo> {……… 
} 


[ 


RequestMappinglnfo 实 现 了 RequestCondition 接 口 ， 此 接口 专门 用 于 保存 从 request 提 取出 的 用 于 匹配 Handler 的 条 件 ， 结 构 如 


12-2 所 示 。 


T RequestCondition 
AbstractRequestCondition 


© RequestMppingInfo 
© CompositeRequestCondition |G© HeadersRequestConditio © ProducesRequestCondition| |G ConsumesRequestCondition 
G PatternsRequestCondition||G RequestConditionHolde 


C RequestMethodsRequestCondition 


图 12-2 RequestCondition 结 构图 


OParamsRequestConditio 


抽象 实现 AbstractRequestCondition 中 重 写 了 equals、hashCode 和 tostring 三 个 方法 ， 有 8 个 子 类 ， 除 了 CompositeRequestCondition 外 每 一 个 子 类 表示 一 种 匹配 条 件 。 比 如 ，PatternsR- 
equestCondition 使 用 url 做 匹配 ，RequestMethodsRequestCondition 使 用 RequestMet-hod 做 匹配 等 。CompositeRequestCondition 本 身 并 不 实际 做 匹配 ， 而 是 可 以 将 多 个 别 的 RequestCondition 者 
装 到 自己 的 一 个 变量 里 ， 在 用 的 时 候 遍 历 封 装 RequestCondition 的 那个 变量 里 所 有 的 RequestCondition 进 行 匹 配 ， 也 就 是 大 家 所 熟悉 的 责任 链 模式 ， 这 种 模式 在 Spring MVC 中 非常 常见 ， 类 名 一 般 是 
CompositeXXX 或 者 XXXComposite 的 形式 ， 它 们 主要 的 作用 就 是 为 了 方便 调用 。 


RequestCondition 的 另 一 个 实现 就 是 这 里 要 用 的 RequestMappinglnfo， 它 里 面 其 实 是 用 七 个 变量 保存 了 七 个 RequestCondition ， 在 匹配 时 使 用 那 七 个 变量 进行 匹配 ， 这 也 就 是 可 以 在 
@RequestMapping 中 给 处 理 器 指定 多 种 匹配 方式 的 原因 。 具 体 的 代码 也 不 难 理解 ， 这 里 就 不 分 析 了 ， 如 果 感 兴趣 可 以 自己 找到 源码 看 一 下 。 下 面 接着 介绍 三 个 Map。 


handlerMethods: 保存 着 匹配 条 件 (也 就 是 RequestCondition) 和 HandlerMethod 的 对 应 关系 。 


urlIMap: 保存 着 url 与 匹配 条 件 (也 就 是 RequestCondition) 的 对 应 关系 ， 当 然 这 里 的 ur| 是 Pattern 式 的 ， 可 以 使 用 通配符 。 另 外 ， 这 里 使 用 的 Map 并 不 是 普通 的 Map， 而 是 MultiValueMap， 这 是 
一 种 一 个 key 对 应 多 个 值 的 Map， 其 实 它 的 value 是 一 个 List 类 型 的 值 ， 看 MultiValueMap 的 定义 就 能 明白 ，MultiValueMap 定 义 如 下 : 


public interface MultiValueMap<K, V> extends Map<K, List<V>> 


由 于 RequestCondition 可 以 同时 使 用 多 种 不 同 的 匹配 方式 而 不 只 是 url 一 种 ， 所 以 反 过 来 说 同一 个 ur| 就 可 能 有 多 个 RequestCondition 与 之 对 应 。 这 里 的 RequestCondition 其 实 就 是 在 
@RequestMapping 中 注释 的 内 容 。 


nameMap: 这 个 Map 是 Spring MVC4 新 增 的 ， 它 保存 着 name 与 HandlerMethod 的 对 应 关系 ， 它 使 用 的 也 是 MultiValueMap 类 型 的 Map， 也 就 是 说 一 个 hame 可 以 有 多 个 Handl-erMethod。 这 里 
的 name 是 使 用 HandlerMethodMappingNamingStrategy 策 略 的 实现 类 从 Hand-lerMethod 中 解析 出 来 的 ， 默 认 使 用 RequestMappinglnfoHandlerMethodMappingNamingStrategy 实 现 类 ， 解 析 规 
则 是 : 类 名 里 的 大 写字 母 组 合 + “#”+ 方 法 名 。 这 个 Map 在 正常 的 匹配 过 程 并 不 需要 使 用 ， 它 主要 用 在 MvcUriComponentsBuilder 里 面 ， 可 以 用 来 根据 name 获 取 相 应 的 url， 比 如 : 


MvcUriComponentsBuilder.MethodArgumentBuilder uriComponents = MvcUriComponentsBuilder 
.fromMappingName ("GC#index"); 
String uri = uriComponents.build(); 


这 样 就 可 以 构造 出 ur 一 一 http://localhost:8080/index， 也 就 是 前 面 定义 的 GoController 的 index 方 法 对 应 的 url，GC 是 GoController 中 的 大 写字 母 。 它 可 以 直接 在 jsp 中 通过 spring 的 标签 来 使 用 ， 如 
<a href="${s:mvcUr| (‘GC#index') }’ >Go</a>。 


这 三 个 Map 怎 么 用 呢 ? nameMap 的 用 法 前 面 已 经 介绍 过 了 ， 下 面 介绍 一 下 urIMap 和 handlerMethods， 前 者 保存 着 url 和 匹配 条 件 的 对 应 关系 ， 可 以 通过 url 拿 到 匹配 条 件 ， 后 者 保存 着 匹配 条 件 与 
HandlerMethod 之 间 的 关系 ， 可 以 通过 前 者 拿 到 的 匹配 条 件 得 到 具体 的 HandlerMethod。 需 要 注意 的 是 前 者 返回 的 有 可 能 是 多 个 匹配 条 件 而 不 是 一 个 ， 这 时 候 还 需要 先 选 出 一 个 最 优 的 ， 然 后 才 可 以 获取 
HandlerMethod。 


理解 了 这 三 个 Map 再 来 看 AbstractHandlerMethodMapping 系 列 的 创建 就 容易 多 了 ，AbstractHandlerMethodMapping 实 现 了 InitializingBean 接 口 ， 所 以 spring 容 器 会 自动 调用 其 
afterPropertiesSet 方 法 ，afterPropertiesSet 又 交 给 initHandlerMethods 方 法 完成 具体 的 初始 化 ， 代 码 如 下 : 


//org.spPringframework.web.servlet.handler.AbstractHandlerMethodMapping 
Public void afterPropertiesSet () { 
initHandlerMethods () 
} 
Protected void initHandlerMethods() { 
if (logger.isDebugEnabled()) { 
logger.debug ("Looking for request mappings in application context: " + getApplicationContext()); 

} 

String[] beanNames = (this.detectHandlerMethodsInAncestorContexts ? 
BeanFactoryUtils.beanNamesForTypeIncludingAncestors (getApplicationContext (), Object.class) : 
getApplicationContext () .getBeanNamesForType (Object .class)); 

for (String beanName : beanNames) { 

if (!beanName.startsWith (SCOPED TARGET NAME PREFIX) && 
isHandler (getApplicationContext () .getType (beanName) ) ) { 
detectHandlerMethods (beanName); 
} 


E 
handlerMethodsInitialized (getHandlerMethods () ) 7 
} 


是 不 是 感觉 似曾相识 ?是 的 ， 在 AbstractDetectingUrlHandlerMapping 里 面 也 有 类 似 的 代码 ， 首 先 拿 到 容器 里 所 有 的 bean， 然 后 根据 一 定 的 规则 筛选 出 Handler， 最 后 保存 到 Map 里 。 这 里 的 筛选 使 
的 方法 是 isHandler， 这 是 一 个 模板 方法 ， 有 具体 实现 在 RequestMapping-HandlerMapping 里 面 ， 筛 选 的 逻辑 是 检查 类 前 是 否 有 @Controller 或 者 @RequestMapping 注 释 ， 代 码 如 下 : 


//org.spPringframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping 
protected boolean isHandler (Class<?> beanType) { 

return ((AnnotationUtils.findAnnotation (beanType, Controller.class) != null) | 

(AnnotationUtils.findAnnotation (beanType, RequestMapping.class) != null)); 


接着 看 initHandlerMethods 方 法 ，detectHandlerMethods 负 责 将 Handler 保 存 到 Map 里 ，handlerMethodslnitialized 可 以 对 Handler 进 行 一 些 初始 化 ， 是 一 个 模板 方法 ， 但 子 类 并 没有 实现 。 下 面 介 
绍 detectHandlerMethods 具 体 是 怎么 工作 的 。 


//org.springframework.web.servlet .handler.AbstractHandlerMethodMapping 
protected void detectHandlerMethods (final Object handler) { 

// 获取 Handler 的 类 型 

Class<?> handlerType = 


(handler instanceof String ? getApplicationContext () .getType ((String) handler) : handler.getClass()); 
// 保存 Handler 与 匹配 条 件 的 对 应 关系 ， 用 于 给 registerHandlerMethod 传 入 匹配 条 件 
final Map<Method, T> mappings = new IdentityHashMap<Method，T> () 7 
// 如 果 是 cglib 代 理 的 子 对 象 类 型 ， 则 返回 父 类 型 ， 否 则 直接 返回 传 入 的 类 型 
final Class<?> userType = ClassUtils.getUserClass (handlerType); 
// 获取 当前 bean 里 所 有 符合 Handler 要 求 的 Method 
Set<Method> methods = HandlerMethodSelector .selectMethods (userType, new MethodFilter () { 
QOverride 
public boolean matches (Method method) { 
T mapping = getMappingForMethod (method, userType); 
if (mapping != null) { 
mappings .Put (method, mapping); 
return true; 
}else { 
return false; 
} 
有 


1 
// 将 符合 要 求 的 Method 注 册 起 来 ， 也 就 是 保存 到 三 个 Map 中 
for (Method method : methods) { 


registerHandlerMethod (handler, method, mappings.get (method)); 
’. 


detectHandlerMethods 方 法 分 两 步 : 首先 从 传 入 的 处 理 器 中 找到 符合 要 求 的 方法 ， 然 后 使 用 registerHandlerMethod 进 行 注册 
方法 所 在 的 类 看 作 处 理 器 了 ， 而 不 是 处 理 请 求 的 方法 ， 不 过 很 多 地 方 需要 使 
了 ,， 比 如，AbstractHandler-MethodMapping 的 getHandlerlnternal 方 法 返 


回 


是 不 是 Handler-Method 类 型 来 判断 的 。 本 书 中 所 说 的 处 理 器 随 当时 的 语 境 可 能 是 指 处 理 请 求 的 方法 也 可 能 指 处 理 请 求 方法 所 在 的 类 。 


从 Handler 里 面 获取 可 以 处 理 请 求 的 Method 的 方法 使 用 了 Handler-MethodSselector.selectMethods， 这 个 方法 可 以 遍历 传 入 的 Handler 的 所 有 方法 ， 然 后 根 


合适 的 方法 。 这 里 的 MethodFilter 使 用 了 匿名 类 ， 具 体 判断 的 逻辑 是 通过 在 匿名 类 里 调 有 
如 果 符 合 要 求 则 会 将 匹配 条 件 保存 到 mappings 里 面 ， 以 备 后 面 使 用 。getMappingForMethod 是 模板 方法 ， 
配 条件 的 ， 如 果 没 有 @RequestMapping 注 释 则 返 | 


回 


//org.spPringframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping 
protected RequestMappingInfo getMappingForMethod (Method method, Class<?> handlerType) { 
RequestMappingInfo info = null; 
RequestMapping methodAnnotation = AnnotationUtils.findAnnotation (method, RequestMapping.class); 
if (methodAnnotation != null) { 
RequestCondition<?> methodCondition = getCustomMethodCondition (method); 
info = createRequestMappingInfo (methodAnnotation, methodCondition); 
RequestMapping typeAnnotation = AnnotationUtils.findAnnotation (handlerType, RequestMapping.class); 
if (typeAnnotation != null) { 
RequestCondition<?> typeCondition = getCustomTypeCondition (handlerType); 
info = createRequestMappingInfo (typeAnnotation, typeCondition) .combine (info); 
} 
} 


return info; 


(也 就 是 保存 到 Map 中 ) 。 从 这 里 可 以 看 出 spring 其 实 是 将 处 理 请 求 的 


处 理 请 求 的 方法 作为 处 理 器 来 理解 才 容 易 理解 ， 而 且 spring 本 身 在 有 些 场景 中 也 将 处 理 请 求 的 方法 HandlerMethod 作 为 处 理 器 
的 处 理 器 就 是 HandlerMethod 类 型 ， 在 Req-uestMappingHandlerAdapter 中 判断 是 不 是 支持 的 Handler 时 也 是 通过 检查 


居 第 二 个 MethodFilter 类 型 的 参数 筛选 出 


getMappingForMethod 人 方法 获取 Method 的 匹配 条 件 ， 如 果 可 以 获取 到 则 认为 符合 要 求 ， 否 则 不 符合 要 求 ， 另 外 


体 实现 在 RequestMappingHandlerMapping 里 ， 它 是 根据 @RequestMapping 注 释 来 找 匹 
回 null， 如 果 有 则 根据 注释 的 内 容 创 建 RequestMappinglnfo 类 型 的 匹配 条 件 并 返回 ， 代 码 如 下 : 


说 完了 怎么 找 HandlerMethod， 再 来 看 一 下 怎么 将 找到 的 HandlerMethod 注 册 到 Map 里 。registerHandlerMethod 的 代码 如 下 : 


//org.spPringframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping 
protected void registerHandlerMethod (Object handler, Method method, T mapping) { 
HandlerMethod newHandlerMethod = createHandlerMethod (handler, method); 
HandlerMethod oldHandlerMethod = this.handlerMethods .get (mapping); 
// 检查 是 否 已 经 在 handlerMethods 中 存在 ， 如 果 已 经 存在 而 且 和 现在 传 入 的 不 同 则 抛 出 异常 
if (oldHandlerMethod != null && !oldHandlerMethod.equals (newHandlerMethod)) { 
throw new IllegalStateException ("Ambiguous mapping found. Cannot map '" + newHandlerMethod.getBean() + 
"! bean method \n" + newHandlerMethod + "\nto " + mapping + ": There is already '"+ 
oldHandlerMethod.getBean() + "' bean method\n" + oldHandlerMethod + " mapped."); 


} 
// 添加 到 handlerMethods 
this.handlerMethods .Put (mapping, newHandlerMethod); 
if (logger.isInfoEnabled()) { 
logger.info ("Mapped \"" + mapping + "\" onto " + newHandlerMethod) ; 


} 
// 添加 到 urlMap 
Set<String> patterns = getMappingPathPatterns (mapping); 
for (String pattern : patterns) { 
if (!getPathMatcher () .isPattern(pattern)) { 
this.urlMap .aqdd (pattern, mapping); 


} 
// 添 加 到 nameMap 
if (this.namingStrategy != null) { 


String name = this.namingStrategy.getName (newHandlerMethod, mapping); 
updateNameMap (name, newHandlerMethod); 


可 以 看 到 这 个 方法 也 非常 简 和 


否则 就 put 进 去 ， 然 后 打印 日 志 ， 具 体 代码 这 里 就 不 提供 了 。 


12.3.2 ”AbstractHandlerMethodMapping 系 列 之 用 


通过 前 面 的 分 析 可 知 这 里 的 主要 功能 是 通过 getHandlerlnterna 人 方法 获取 处 理 器 ，getHand-lerlnternal 的 代码 如 下 : 


， 首 先 检 查 一 下 handlerMethods 这 个 Map 里 是 不 是 已 经 有 这 个 匹配 条 件 了 ， 如 果 有 而 且 所 对 应 的 值 和 现在 传 入 的 HandlerMethod 不 是 同一 个 则 抛 出 异常 ， 否 则 依次 添加 
到 三 个 Map 里 。 在 往 nameMap 里 添加 的 时 候 需要 先 解析 出 name 然 后 调用 updateNameMap 方 法 进行 添加 ，updateNameMap 方 法 也 非常 简单 ， 大 概 过 程 就 是 先 检查 是 不 是 已 经 存在 ， 如 果 存 在 就 返回 


1 


// org.springframework.web.servlet.handler.AbstractHandlerMethodMapping 
protected HandlerMethod getHandlerInternal (HttpServletRequest request) throws Exception { 
String lookupPath = getUrlPathHelper() .getLookupPathForRequest (request); 
HandlerMethod handlerMethod = lookupHandlerMethod (lookupPath, request); 
return (handlerMethod != null ? handlerMethod.createWithResolvedBean() : null); 
} 


这 里 省 略 了 日 志 相关 代码 ， 可 以 看 到 实际 就 做 了 三 件 寻 
handlerMethod; 第 三 件 是 如 果 可 以 找到 handlerMethod 则 调用 它 的 creat-eWithResolvedBean 方 法 创建 新 的 HandlerMethod 并 返回 
handler 是 不 是 String 类 型 ， 如 果 是 则 改 为 将 其 作为 beanName 从 容器 中 所 取 到 的 bean， 不 过 HandlerMethod 里 的 属性 都 是 final 类 型 的 
属性 和 修改 后 的 handler 新 建 了 一 个 HandlerMethod。 下 面 来 看 一 下 具体 查找 HandlerMethod 的 方法 lookupHandlerMethod。 


: 第 一 件 是 根据 request 获 取 lookupPath， 可 以 简单 地 理解 为 url; 第 二 件 是 使 用 lookupHandlerMethod 方 法 通过 lookup-Path 和 request 找 


，createWithResolvedBean 的 作用 是 判断 handlerMethod 里 的 
， 不 可 以 修改 ， 所 以 在 createWithResolvedBean 方 法 中 又 用 原来 的 


// org.springframework.web.servlet.handler.AbstractHandlerMethodMapping 
protected HandlerMethod lookupHandlerMethod (String lookupPath, HttpServletRequest request) throws Exception { 
// Match 是 内 部 类 ,保存 匹配 条 件 和 Handler 
List<Match> matches = new ArrayList<Match>(); 
// 首先 根据 lookupPath 获 取 到 匹配 条 件 
List<T> directPathMatches = this.urlMap.get (lookupPath); 
if (directPathMatches != null) { 


// 将 找到 的 匹配 条 件 添 加 到 matches 
addMatchingMappings (directPathMatches, matches, request); 


， 
// 如 果 不 能 直接 使 用 1ookupPath 得 到 匹配 条 件 ， 
if (matches.isEmpty()) { 
addMatchingMappings (this.handlerMethods .keySet (), matches, request); 


则 将 所 有 匹配 条 件 加 入 matches 


// 将 包含 匹配 条 件 和 Handler 的 matches 排 序 ， 并 取 第 一 个 作为 bestMatch， 如 果 前 面 两 个 排序 相同 则 抛 出 异常 
if (!matches.isEmpty()) { 
Comparator<Match> comparator = new MatchComparator (getMappingComparator (request)); 
Collections.sort (matches, comparator); 
if (logger.isTraceEnabled()) { 
logger.trace ("Found " + matches.size() + " matching mapping(s) for [" + lookupPath + "] 
} 
Match bestMatch = matches.get (0); 
if (matches.size() > 1) { 
Match secondBestMatch = matches.get (1); 
if (comparator.compare (bestMatch, secondBestMatch) == 0) { 
Method ml = bestMatch.handlerMethod.getMethod () 7 
Method m2 = secondBestMatch.handlerMethod.getMethod(); 
throw new IllegalStateException( 


"Ambiguous handler methods mapped for HTTP path '" + request.getRequestURL() + ™': 


} 
handleMatch (bestMatch.mapping, lookupPath, request); 
return bestMatch.handlerMethod; 
}else { 
return handleNoMatch (handlerMethods .keySet (), lookupPath, request); 
} 
} 


详细 过 程 已 经 做 了 注释 ， 比 较 容易 理解 ， 整 个 过 程 中 是 使 用 Match 作 为 载体 的 ，Match 是 个 内 部 类 ， 


: "+ matches) 7 


tr+m+wn+m2+en; 


封装 了 匹配 条 件 和 HandlerMethod 两 个 属性 。handleMatch 方 法 是 在 返回 前 做 一 些 处 理 ， 默 认 实 


现 是 将 lookupPath 设 置 到 request 的 属性 ， 子 类 RequestMappinglnfo-HandlerMapping 中 进行 了 重 写 


四 和 


本 章 详细 分 析 了 Spring MVC 中 的 HandlerMapping 的 各 种 


方法 是 通过 几 个 与 Interceptor 相 关 的 Map 完 成 的 ， 在 初始 化 过 程 中 对 那些 Map 进 行 了 初始 化 。 


， 将 更 多 的 参数 设置 到 了 request 的 属性 ， 主 : 


体 实现 方式 。HandlerMapping 的 整体 结构 在 AbstractHandlerMapping 中 设计 ， 和 简单 来 说 
Interceptors， 组 合成 HandlerExecutionChain 类 型 并 返回 。 找 Handler 的 过 程 通 过 模板 方法 getHandlerinternal 留 给 子 类 实现 ， 查 找 Interceptors 则 是 AbstractHandlerMapping 自 己 完成 的 


是 为 了 以 后 使 用 时 方便 ， 跟 Mapping 没 有 关系 。 


功能 就 是 根据 request 找 到 Handler 和 
， 查 找 的 具体 


AbstractHandlerMapping 的 子 类 分 了 两 个 系列 : AbstractUrlHandlerMapping 系 列 和 Abstract-HandlerMethodMapping 系 列 ， 前 者 是 通过 url 匹 配 的 ， 后 者 匹配 的 内 容 比较 多 ， 而 且 是 直接 匹配 到 


Method， 这 也 是 现在 使 


最 多 的 一 种 方式 。 


第 13 章 HandlerAdapter 


HandlerMapping 通 过 request 找 到 了 Handler，HandlerAdapter 是 具体 使 


Handler 来 


示 。 


T HandlerAdapter 


活 的 ,每 个 HandlerAdapter 封 装 了 一 种 Handler 的 具体 使 


方法 。HandlerAdapter 的 继承 结构 如 


13-1 所 


[ 


© AbstratHandlerMethodAdapter| |G |[@ HupRequestHandlerAdaptel C © SimpleContollerHandlerAdapter Adapter| |G AnnetationMethodHandlerAdapter 本 要 本 天 C |G simpleserletHandlerAdapted 


le RedquestMappingHandlerAdapte 


13-1 HandlerAdapter 


结构 图 


可 以 看 到 HandlerAdapter 的 结构 非常 简单 ， 一 共有 5 类 Adapter， 其 中 只 有 Request-MappingHandlerAdapter 有 两 层 ， 别 的 都 是 只 有 一 层 ， 也 就 是 直接 实现 的 HandlerAdapter 接 | 
AnnotationMethodHandlerAdapter 已 经 标注 了 @Deprecated 被 弃 用 ， 所 以 总 共 就 只 有 4 类 Adapter，5 个 类 。 在 这 四 类 Adapter 中 RequestMappingHandlerAdapter 的 实现 非常 复杂 ， 而 
常 简单 ， 因 为 其 他 三 个 Handler 的 格式 都 是 固定 的 ， 只 需要 调用 固定 的 方法 就 可 以 了 ， 但 是 RequestMappingHandlerAdapter 所 处 理 的 Handler 可 以 是 任意 的 方法 ， 没 有 任何 约束 ， 


。 和 而 且 

他 三 个 则 非 
这 就 极 大 地 增加 了 难 
而 且 有 几 个 参数 也 不 确定 ， 如 果 让 我 们 去 做 ， 我 们 会 怎么 做 呢 ? 大 家 可 以 先 自己 思 


度 。 其 实 调用 并 不 算 难 ， 大 家 应 该 都 可 以 想到 ， 使 用 反射 就 可 以 了 ， 关 键 是 参数 值 的 解析 ， 参 数 可 能 有 各 种 各 样 的 类 型 ， 
考 一 下 。 
前 面 已 经 讲 过 HandlerAdapter 的 接口 了 ， 里 面 一 共有 三 个 方法 ， 一 个 用 来 判断 是 否 支 持 传 入 的 Handler， 


HttpRequestHandlerAdapter、 
Handler 里 固定 的 方法 ， 代 码 如 下 : 


一 个 用 来 使 用 Handler 处 理 请 求 ， 还 有 一 个 


SimpleServletHandlerAdapter 和 SimpleControllerHandler-Adapter 分 别 适 配 HttpRequestHandler、Servlet 和 Controller 类 型 的 Handler,， 方法 非常 简单 ， 


用 来 获取 资源 的 Last-Modified 值 。 


都 是 调 


//org.springframework.web.servlet .mvce.HttpRequestHandlerAdapter 


public ModelAndView handle (HttpServletRequest request, HttpServletResponse response, Object handler) 


throws Exception { 
( (HttpRequestHandler) handler) .handleRequest (request, response); 
return null; 
} 


// org.springframework.web.servlet.handler.SimpleServletHandlerAdapter 


public ModelAndView handle (HttpServletRequest request, HttpServletResponse response, Object handler) 


throws Exception { 
((Servlet) handler) .service (request, response); 
return null; 
} 


//org.springframework.web.servlet .mvc.SimpleControllerHandlerAdapter 


public ModelAndView handle (HttpServletRequest request, HttpServletResponse response, Object handler) 


throws Exception { 
return ((Controller) handler) .handleRequest (request, response); 


这 三 个 Adapter 非 常 简单 ， 这 里 就 不 多 说 了 ， 接 下 来 要 分 析 的 RequestMappingHandler-Adapter 就 没 这 么 简单 了 。 


ls 


RequestMappingHandlerAdapter 概 述 


RequestMappingHandlerAdapter 继 承 自 AbstractHandlerMethodAdapter， 后 者 非常 简单 ， 三 个 接口 方法 分 别 调用 了 三 个 模板 方法 supportslnternal、handlelnternal 和 
getLastModifiedlnternal， 在 supports 方 法 中 除了 supportslnternal 还 增加 了 个 条 件 一 一 Handler 必 须 是 HandlerMethod 类 型 。 另 外 实现 了 Order 接 口 ， 可 以 在 配置 时 设置 顺序 ， 代 码 如 下 : 


Package org.springframework.web.servlet.mvc.method; 
// 省 略 了 imports 
public abstract class AbstractHandlerMethodAdapter extends WebContentGenerator implements HandlerAdapter, Ordered { 


private int order = Ordered.LOWEST PRECEDENCE; 
public AbstractHandlerMethodAdapter() { 
// no restriction of HTTP methods by default 
super (false); 
} 
public void setOrder (int order) { 
this.order = order; 
} 
QOverride 
public int getOrder() { 
return this.order; 
} 
QOverride 
public final boolean supports (Object handler) { 
return (handler instanceof HandlerMethod && supportsInternal ( (HandlerMethod) handler)); 
} 
protected abstract boolean supportsInternal (HandlerMethod handlerMethod); 
QOverride 
public final ModelAndView handle (HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { 
return handleInternal (request, response, (HandlerMethod) handler); 


} 
protected abstract ModelAndView handleInternal (HttpServletRequest request, 
HttpServletResponse response, HandlerMethod handlerMethod) throws Exception; 
QOverride 
public final long getLastModified (HttpServletRequest request, Object handler) { 
return getLastModifiedInternal (request, (HandlerMethod) handler); 
: 
protected abstract long getLastModifiedIinternal (HttpServletRequest request, HandlerMethod handlerMethod); 


接 下 来 看 RequestMappingHandlerAdapter，RequestMappingHandlerAdapter 可 以 说 是 整个 Spring MVC 中 最 复杂 的 组 件 。 它 的 supportsinternal 直 接 返 | 


回 


true， 也 就 是 不 增加 判断 Handler 的 条 


件 ， 只 需要 满足 父 类 中 的 HandlerMethod 类 型 的 要 求 就 可 以 了 ; getLastModifiedlnternal 直 接 返回 -1; 最 重要 的 就 是 handlelnternal 方 法 ， 就 是 这 个 方法 实际 使 用 Handler 处 理 请 求 。 具 体 处 理 过 程 大 致 
可 以 分 为 三 步 : 


1) 备 好 处 理 器 所 需要 的 参数 。 


2) 使 用 处 理 器 处 理 请 求 。 


3) 处 理 返回 值 ， 也 就 是 将 不 同类 型 的 返回 值 统一 处 理 成 ModelAndView 类 型 。 


这 三 步 里 面 第 2 步 是 最 简单 的 ， 直 接 使 用 反射 技术 调用 处 理 器 执行 就 可 以 了 ， 第 3 步 也 还 算 简单 ， 最 麻烦 的 是 第 1 步 ， 也 就 是 参数 的 准备 工作 ， 这 一 步 根据 处 理 器 的 需要 设置 参数 ， 而 参数 的 类 型 、 个 数 
都 是 不 确定 的 ， 所 以 难度 非常 大 ， 另 外 这 个 过 程 中 使 用 了 大 量 的 组 件 ， 这 也 是 这 一 步 的 代码 不 容易 理解 的 重要 原因 之 一 。 


想 理解 参数 的 绑 定 需要 先 想 明白 三 个 问题 : 


“ 都 有 哪些 参数 需要 绑 定 。 


“ 参数 的 值 的 来 源 。 


“ 具体 进行 绑 定 的 方法 。 


需要 绑 定 的 参数 当然 是 根据 方法 确定 了 ， 不 过 这 里 的 方法 除了 实际 处 理 请 求 的 处 理 器 之 外 还 有 两 个 方法 的 参数 需要 绑 定 ， 那 就 是 跟 当前 处 理 器 相对 应 的 注释 了 @ModelAttribute 和 注释 了 @InitBinder 


的 方法 。 


参数 来 源 有 6 个 : 


“ request 中 相关 的 参数 ， 主 要 包括 utl 中 的 参数 、post 过 来 的 参数 以 及 请 求 头 所 包含 的 值 。 


* cookie 中 的 参数 。 


“session 中 的 参数 。 


“ 设置 到 FlashMap 中 的 参数 ， 这 种 参数 主要 用 于 redirect 的 参数 传递 。 


SessionAttributes 传 递 的 参数 ， 这 类 参数 通过 (@SessionAttributes 注 释 传 递 ， 后 面 会 详细 讲解 。 


: 通过 相应 的 注释 了 @ModelAttribute 的 方法 进行 设置 的 参数 。 


参数 具体 解析 是 使 用 HandlerMethodArgumentResolver 类 型 的 组 件 完成 的 ， 不 同类 型 的 参数 使 用 不 同 的 ArgumentResolver 来 解析 。 有 的 Resolver 内 部 使 用 了 WebDataBinder， 可 以 通过 注释 了 
@InitBinder 的 方法 来 初始 化 。 注 释 了 @InitBinder 的 方法 也 需要 绑 定 参数 ， 而 且 也 是 不 确定 的 ， 所 以 @lnitBinder 注 释 的 方法 本 身 也 需要 ArgumentResolver 来 解析 参数 ， 但 它 使 用 的 和 Handler 使 用 的 不 是 
同一 套 ArgumentResolver。 另 外 ， 注 释 了 @MeodelAttribute 的 方法 也 需要 绑 定 参数 ， 它 使 用 的 和 Handler 使 用 的 是 同一 套 ArgumentResolver。 


多 知道 点 


@lInitBinder、@ModelAttribute 以 及 @ControllerAdvice 的 作用 


有 人 @InitBinder 注 释 的 方法 用 于 初始 化 Binder， 我 们 可 以 在 其 中 做 一 些 Binder 初 始 化 的 工作 ， 如 可 以 注册 校 验 器 、 注 册 自 己 的 参数 编辑 器 等 。 比 如 ， 可 以 在 Controller 中 通过 下 面 的 代码 注册 一 个 转换 Date 类 
型 的 编辑 器 ， 这 样 就 可 以 将 “yyyy-MM-dd” 类 型 的 String 转 换 成 Date 类 型 。 


@InitBinder 

public void initBinder (WebDataBinder binder) { 

SimpleDateFormat dateFormat = new SimpleDateFormat ("yyyy-MM-dd"); 

dateFormat .setLenient (false); 

binder.registerCustomEditor (Date.class, new CustomDateEditor (dateFormat, false)); 


} 


这 个 编辑 器 会 将 类 似 “2015-01-01” 的 字符 串 转换 成 Date 类 型 的 日 期 。Spring 已 经 给 我 们 提供 了 很 多 默认 的 编辑 器 ， 最 常用 的 编辑 器 是 数字 编辑 器 和 日 期 编辑 器 ， 但 有 时 候 在 一 些 特殊 的 情况 下 也 需要 我 


们 自己 来 定制 编辑 器 ， 笔 者 在 以 前 做 的 一 个 项 目 里 面 有 一 个 分 析 数 据 的 功能 ， 作 用 是 根据 选 定 的 参数 对 后 台数 据 进行 分 析 ， 不 过 需要 传递 的 参数 非常 灵活 ， 传 入 什么 参数 并 不 是 国定 的 ， 而 且 每 个 参数 都 可 
能 有 多 个 值 ， 其 中 的 参数 有 所 分 析 数 据 的 时 间 范 围 、 数 据 所 属 的 单位 (可 以 有 多 个 ， 而 且 单位 还 分 了 三 个 层次 ) 、 什 么 产品 的 数据 、 数 据 需要 满足 的 特性 、 对 哪个 变量 进行 分 析 等 ， 而 且 每 个 参数 都 可 以 为 
空 也 可 以 有 多 个 值 ， 这 一 个 页 面 其 实 就 相当 于 一 个 小 程序 了 ， 当 时 我 设计 的 传递 参数 的 方案 是 将 所 有 的 变量 都 通过 一 个 参数 来 传递 ， 参 数 的 类 型 类 似 于 前 面 介绍 的 MultiValueMap， 一 个 key 多 个 Value 的 Map， 


不 过 当时 使 用 的 并 不 是 MultiValueMap 而 是 用 了 自 定义 的 类 型 。 在 这 种 情况 下 就 需要 自己 来 定制 一 个 编辑 器 了 。 


我 们 再 来 看 一 个 注册 校 验 器 的 例子 ，Spring MVC 中 参数 校 验 非常 简单 ， 只 需要 在 ModelAttribute 类 型 的 参数 (这 种 参数 不 一 定 前面 都 有 @ModelAttribute 注 释 ， 后 面 有 详细 介绍 ) 前 注释 @Valid 或 者 


@Validated 就 可 以 了 ， 不 过 具体 校 验 是 通过 Binder 中 的 校 验 器 来 做 的 ， 所 以 需要 提前 给 Binder 注 册 校 验 器 ， 下 面 这 个 例子 ， 首 先 新 建 一 个 User 类 和 一 个 相应 的 校 验 器 UserValidator。 


public class User { 
String userName; 
public String getUserName () { 
return userName; 


public void setUserName (String userName) { 
this.userName = userName; 
} 
} 
@Component 
public class UserValidator implements Validator { 
QOverride 
public boolean supports (Class<?> paramClass) { 
return User.class.equals (paramClass); 
} 


QOverride 
public void validate (Object obj, Errors errors) { 
User user = (User) obj; 


if (user.getUserName () .length()<8) { 
errors.rejectValue ("userName", "valid.userNameLen", new Object[]{"minLength" ,8}, "用 户 名 不 能 少 于 {1} 位 "); 
} 


User 里 只 有 一 个 属性 userName，UserValidator 中 判断 User 的 userName 的 长 短小 于 8 位 ， 如 果 是 则 添加 到 错误 中 。 然 后 再 写 一 个 处 理 器 。 


QController 
@RequestMapping ("/valid") 
public class ValidatorController { 
QAutowired 
private UserValidator validator; 
QInitBinder 
Private void initBinder (WebDataBinder binder) { 
binder.addValidators (validator); 
} 
QRequestMapping (value={"/index", "/", ""},method= {RequestMethod.GET}) 
public String index (ModelMap m) throws Exception { 
m.addAttribute ("user", new User()); 
return "user.jsp"; 


} 

@RequestMapping (value={"/signup"},method= {RequestMethod.POST}) 

public String signup( Q@Valid User user, BindingResult br, RedirectAttributes ra) throws Exception { 
ra.addFlashAttribute ("user", user); 


return " user.jsp "7 


这 样 就 将 校 验 器 添加 到 Binder 中 了 ，WebDataBindet 添 加 校 验 器 有 两 个 方法 ， 一 个 是 addValidators ， 另 一 个 是 setValidator。 前 者 是 在 原 有 的 基础 上 添加 的 ， 后 者 是 直接 设置 成 现在 的 ， 如 果 原 来 有 校 验 器 会 


被 替换 掉 。 下 面 来 写 一 个 测试 页 面 userjsp。 


<%Q@ taglib prefix="spring" uri="http://www.springframework.org/tags" %> 
<%@ taglib prefix="form" uri="http://www.springframework.org/tags/form" %> 
<$Q@ page contentType="text/html;charset=UTF-8" language="java" 和 > 

<html> 

<head> 

<title>validate user</title> 

</head> 

<body> 

<form: form commandName="user" action="/valid/signup" method="POST" > 
<form:errors path="*"/><br/> 用 户 名 <form:input path="userName"/><form:errors path="userName"/> 
</form: form> 

</body> 

</html> 


这 里 使 用 了 spring 的 form:errors 标 签 来 输出 校 验 失败 信息 ， 用 path 设 定 需 要 显示 校 验 错误 的 参数 ，path 为 *" 会 输出 所 有 校 验 失败 信息 。 当 输入 一 个 时， 显示 结 果 如 


[9 validate user 


所 © DD localhost:8080/valid/signup 


- 


用 户 名 不 能 少 于 8 位 


用 户 名 上 用 户 名 不 避 少 于 8 位 


13-2 校 验 错误 显示 结果 


在 注释 了 GOInitBinder 的 初始 化 方法 中 还 可 以 对 Binder 做 更 多 设置 ， 这 里 就 不 一 一 介绍 了 。 


@ModelAttribute 注 释 如 果 用 在 方法 上 ， 则 用 于 设置 参数 ， 它 会 在 执行 处 理 前 将 参数 设置 到 Model 中 。 其 规则 是 如 果 @ModelAttribute 设 置 了 value 则 将 其 作为 参数 名 ， 返 回 值 作为 参数 值 设 置 到 Model; 如 果 
方法 含有 Model、Map 或 者 ModelMap 类 型 的 参数 ， 则 可 以 直接 将 需要 设置 的 参数 设置 上 去 ; 如 果 既 没有 设置 value 也 没有 Model 类 型 的 参数 则 根据 返回 值 类 型 解析 出 参数 名 (具体 逻辑 在 ModelFactory 中 讲解 ) ， 


13-2 所 示 。 


返回 值 作为 参数 值 设置 到 Model。 来 看 个 例子 就 明白 了 ， 将 下 面 的 代码 放 到 前 面 的 GoController 中 


// 执 行 处 理 前 给 Mode1 设 置 ("className "，" com.excelib.controller.GoController ") 
@ModelAttribute ("className") 
public String setModel() throws IOException { 
return this.getClass () .getName (); 


} 

// 执 行 处 理 前 给 Model 设 置 ("teacher"，" 和 孔 老 夫子 ") 

@ModelAttribute 

public void setModell (Model model) throws IOException { 
model .addAttribute ("teacher"，" 孔 老夫 子 "); 


} 
// 执 行 处 理 前 给 Model 设 置 ("string"，"excelib") 
QModelAttribute 
public String setModel2() throws IOException { 
return "excelib"; 
} 
@RequestMapping (value={"/index","/"},method= {RequestMethod.GET}) 
public String index (HttpServletRequest request, Model model) throws Exception { 
Map m = model .asMap (); 
logger.info("className"+"——>"+m.get ("className")); 
logger .info ("teacher"+" 一 一 : ("teacher") ) 7 
1ogger .info ("string"+" "+m.get ("string")); 
model .addAttribute ("msg", "Go Go Go!™"); 
return "go.jsp"; 


i 


执行 后 在 处 理 器 中 日 志 打 印 如 下 : 


className——>com.excelib.controller.GoController 


teacher 一 一 > 和 孔 老 夫子 
string——>excelib 


可 见 这 里 的 值 在 处 理 器 执行 前 已 经 设置 到 Model 中 了 ， 它 的 作用 就 是 这 样 。 需 要 注意 的 是 @ModelAttribute 只 有 注释 在 方法 上 才 是 这 种 用 途 ， 如 果 注 释 在 参数 上 则 表示 需要 使 用 指定 的 ArgumentResolver 来 
解析 参数 ， 具 体内 容 在 后 面 详细 讲解 。 男 外 ， 如 果 @ModelAttribute 所 注释 的 方法 也 有 @RequestMapping 注 释 ， 同 时 也 是 一 个 处 理 器 则 就 不 会 提前 执行 了 (无 论 当 前 请 求 是 不 是 使 用 的 这 个 处 理 器 ) ， 这 时 候 的 
作用 只 是 在 使 用 这 个 处 理 器 处 理 完 请 求 后 不 会 将 返回 值 作为 View， 而 是 设置 到 Model 中 供 泻 染 使 用 ， 因 为 处 理 器 本 身 就 可 以 设置 Model， 所 以 这 种 用 法 的 意义 并 不 很 大 。 


前 面 所 说 的 @InitBinder、@ModelAttribute 都 是 定义 到 特定 的 处 理 器 里 面 才能 起 作用 ， 如 果 想 在 所 有 处 理 器 中 都 起 作用 怎么 办 呢 ? 最 省 心 的 办 法 就 是 在 每 个 Controller 中 copy 一 份 代码 ， 这 种 做 法 的 兽 端 大 
家 都 明白 ， 除 非 没 有 别 的 办 法 ， 和 否则 是 不 会 采取 这 种 方法 的 。 稍 徽 好 点 的 做 法 是 定义 一 个 Conttoller 的 基 类 ， 让 所 有 Conttoller 都 继承 它 ， 然 后 将 @InitBinder、@ModelAttribute 注 释 的 方法 定义 到 里 面 。 这 种 方 
法 虽然 可 行 ， 但 是 如 果 在 很 多 Controller 已 经 完成 编码 并 且 通 过 测试 的 情况 下 ， 改 起 来 还 是 很 麻烦 的 ， 如 果 有 的 Conttoller 还 继承 了 别 的 类 (特别 是 继承 的 jar 包 里 的 类 而 不 是 自己 开发 的 类 的 时 候 ) 麻烦 就 更 大 
了 。Spring MVC 提 供 了 一 种 非常 简单 的 解决 方法 ， 我 们 只 需要 定义 一 个 类 ， 然 后 在 类 前 加 上 (@ControllerAdvice 注 释 ， 并 将 @InitBinder、@ModelAttribute 注 释 的 方法 放 进 去 就 可 以 了 ， 这 样 每 个 Handler 调 用 前 
都 会 调用 这 些 方法 。 从 Spring MVC4.0 开 始 @ControllerAdvice 注 释 添加 了 value、basePackages、basePackageClasses、assignableTypes 和 annotations 五 个 参数 ， 可 以 通过 它们 选择 将 这 些 方法 用 于 哪些 Controller， 而 不 
是 必须 用 于 所 有 的 Controller。Value 是 basePackages 的 别名 ， 表 示 配 置 基 础 包 ; basePackageClasses 是 basePackages 类 型 安全 替代 品 ， 它 会 扫描 配置 类 所 在 包 的 所 有 类 ， 如 设置 com.excelib.controller.GoController 后 会 


扫描 com.excelib.controller 包 中 所 有 的 类 ; assignableTypes 和 annotations 分 别 指定 具体 的 类 和 类 所 包含 的 注释 。 
另外 ，Spring MVC4.1 中 新 增 了 ResponseBodyAdvice 接 口 ， 实 现 了 这 个 接口 的 类 可 以 修改 返回 值 直 接 作 为 ResponseBody 类 型 的 处 理 器 的 返回 值 。 有 两 种 类 型 的 处 理 器 会 将 返回 值 作为 ResponseBody: 
“ 返回 值 为 HttpEntity 类 型 。 
“ 返回 值 (或 处 理 器 方法 ) 前 注释 了 @ResponseBody。 


这 两 种 处 理 器 的 返回 值 就 可 以 被 实现 了 ResponseBodyAdvice 接 口 的 类 修改 。ResponseBodyAdvice 实 现 类 实际 主要 用 于 修改 json 类 型 的 返回 值 ， 可 以 在 里 边 统一 做 一 些 处 理 。 实 现 了 ResponseBodyAdvice 接 口 
的 类 会 在 相应 处 理 器 处 理 完 请 求 后 被 相应 的 ReturnValueHandler 调 用 ，ReturnValueHandlet 是 用 来 处 理 Handler 的 返回 值 的 ， 后 面 详细 介 绍 。 要 想 让 这 些 类 生效 ， 必 须 将 其 注册 到 Spring MVC 的 容器 中 。 注 册 的 方 
法 有 两 种 : 一 种 是 注册 到 RequestMappingHandlerAdapter 中 ， 另 一 种 是 直接 给 实现 了 ResponseBodyAdvice 接 口 的 类 添加 @ControllerAdvice 注 释 ， 这 样 spring 就 可 以 自动 发 现 并 将 其 注册 到 容器 里 了 。 如 下 实例 ， 首 
先 新 建 一 个 实现 了 ResponseBodyAdvice 接 口 的 类 ， 然 后 暂时 在 原来 处 理 器 方法 前 添加 @ResponseBody 注 释 。 


Q@ControllerAdvice 
public class HahaResponseBodyAdvice implements ResponseBodyAdvice<String> { 
QOverride 
public boolean supports (MethodParameter returnType, Class<? extends HttpMessageConverter<?>> converterType) { 
return true; 
} 
QOverride 
public String beforeBodyWrite (String body, MethodParameter returnType, MediaType selectedContentType, 
Class<? extends HttpMessageConverter<?>> selectedConverterType, 
ServerHttpRequest request, ServerHttpResponse response) { 
return body+"<br/> haha,this is been modified"; 
} 
} 
//com.excelib.controller.GoController 
// 在 处 理 器 返回 值 前 暂时 添加 @ResponseBody 注 释 
@RequestMapping (value={"/index","/"},method= {RequestMethod.GET}) 
@ResponseBody public String index (HttpServletRequest request, Model model) throws Exception { 
model .addAttribute ("msg", "Go Go Go!"); 
return "go.jsp"; 


这 里 HahaResbonseBodyAdvice 中 的 supports 方 法 直接 返回 true， 表 示 所 有 返回 ResponseBody 的 处 理 器 返回 值 它 都 要 修改 ， 具 体 修改 的 方法 beforeBodyWrite 中 是 在 原来 的 内 容 后 面 添加 了 "<br/>haha,this is been 
modified"。 处 理 器 方法 index 添 加 @ResponseBody 注 释 后 返回 的 "go.jsp" 就 不 代表 视图 页 面 了 ， 而 是 直接 将 其 内 容 显示 到 浏览 器 中 ， 再 通过 HahaResponseBodyAdvice 的 修改 ， 最 后 会 返回 给 浏览 


器 "go.jsp<br/>hahathis is been modified"。 当然 这 里 的 代码 只 是 为 了 说 明 ResponseBodyAdvice 的 使 用 方法 ， 并 没有 什么 实际 意义 。 浏 览 器 访问 后 的 结果 如 图 13-3 所 示 。 


[9 localhost:8080 


haha, this is been modified 


图 13-3 ” ResponseBodyAdvice 修 改 后 返回 结果 截图 


由 于 RequestMappingHandlerAdapter 里 面 涉及 的 组 件 比较 多 ， 而 且 大 都 充当 着 非常 重要 的 角色 ， 所 以 先 分 析 RequestMappingHandlerAdapter 自 身 的 结构 ， 然 后 单独 对 它 所 包含 的 组 件 进行 分 析 。 


13.2 RequestMappingHandlerAdapter 自 身 结构 


RequestMappingHandlerAdapter 自 身 的 结构 其 实 并 不 复杂 ， 不 过 其 中 使 用 了 很 多 组 件 ， 如 果 不 知道 那些 组 件 的 作用 就 很 难 对 源码 进行 分 析 。 通 过 前 面 的 介绍 大 家 应 该 已 经 对 其 大 致 轮廓 有 了 一 定 的 
认识 了 ， 这 也 就 给 理解 详细 的 结构 以 及 所 用 到 的 组 件 打下 了 基础 。 本 节 会 在 涉及 别 的 组 件 的 地 方 先 大 概 介绍 一 下 ， 知 道 大概 起 什么 作用 就 可 以 了 ， 后 面 再 对 关键 的 组 件 详细 分 析 。 


13.2.1 创建 RequestMappingHandlerAdapter 之 器 


RequestMappingHandlerAdapter 的 创建 在 afterPropertiesSet 方 法 中 实现 ， 其 内 容 主要 是 初始 化 了 argumentResolvers、initBinderArgumentResolvers、returnValueHandlers 以 及 
@ControllerAdvice 注 释 的 类 相关 的 modelAttributeAdviceCache、initBinderAdviceCache 和 responseBodyAdvice 这 6 个 属性 ， 下 面 分 别 介绍 这 6 个 属性 。 


“ argumentResolvers: 用 于 给 处 理 器 方法 和 注释 了 @ModelAttribute 的 方法 设置 参数 。 
:initBinderArgumentResolvers: 用 于 给 注释 了 (@initBindet 的 方法 设置 参数 。 
“ returnValueHandlers: 用 于 将 处 理 器 的 返回 值 处 理 成 ModelAndView 的 类 型 。 


“ modelAttributeAdviceCache 和 initBinderAdviceCache: 分 别 用 于 缓存 @ControllerAdvice 注 释 的 类 里 面 注 释 了 (@ModelAttribute 和 (@InitBinder 的 方法 ， 也 就 是 全 局 的 @ModelAttribute 和 (@InitBindert 方 法 。 每 个 
处 理 器 自己 的 @ModelAttribute 和 人 @InitBinder 方 法 是 在 第 一 次 使 用 处 理 器 处 理 请 求 时 缓存 起 来 的 ， 这 种 做 法 既 不 需要 启动 时 就 花 时 间 遍 历 每 个 Controller 查 找 @ModelAttribute 和 人 @InitBinder 方 法 ， 又 能 在 调用 过 
一 次 后 再 调用 相同 处 理 器 处 理 请 求 时 不 需要 再 次 查找 而 从 缓存 中 获取 。 这 两 种 缓存 的 思路 类 似 于 单 例 模式 中 的 馈 汉 式 和 懒汉 式 。 


“ tesponseBodyAdvice: 用 来 保存 前 面 介绍 过 的 实现 了 ResponseBodyAdvice 接 口 、 可 以 修改 返回 的 ResponseBody 的 类 。 


把 这 些 都 弄 明白 ， 再 分 析 RequestMappingHandlerAdapter 就 容易 多 了 ， 需 要 注意 的 是 ， 这 些 属性 都 是 复数 形式 ， 也 就 是 可 以 有 多 个 ， 在 使 用 的 时 候 是 按 顺 序 调用 的 ， 所 以 这 些 属性 初始 化 时 的 添加 
顺序 就 非常 重要 了 ， 大 家 要 留意 一 下 。afterPropertiesSet 的 代码 如 下 : 


// org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerRdapter 
public void afterPropertiesSet () { 
// 初始 化 注释 了 ControllerRdvice 的 类 的 相关 属性 
initControllerAdviceCache () 7 
if (this.argumentResolvers 一 null) { 
List<HandlerMethodArgumentResolver> resolvers = getDefaultArgumentResolvers () 7 
this.argumentResolvers = new HandlerMethodArgumentResolverComposite() .addResolvers (resolvers); 
} 
if (this.initBinderArgumentResolvers == null) { 
List<HandlerMethodArgumentResolver> resolvers = getDefaultInitBinderArgumentResolvers (); 
this.initBinderArgumentResolvers = new HandlerMethodArgumentResolverComposite() .addResolvers (resolvers); 
} 
if (this.returnValueHandlers == null) { 
List<HandlerMethodReturnValueHandler> handlers = getDefaultReturnValueHandlers (); 
this.returnValueHandlers = new HandlerMethodReturnValueHandlerComposite () .addHandlers (handlers); 
} 


非常 清晰 的 4 步 ， 首 先 initControllerAdviceCache 初 始 化 注释 了 @ControllerAdvice 的 类 的 那 三 个 属性 ， 然 后 依次 初始 化 argumentResolvers、initBinderArgumentResolvers 和 return- 
ValueHandlers。 后 面 三 个 属性 初始 化 的 方式 都 一 样 ， 都 是 先 调用 getDefaultXXX 得 到 相应 的 值 ， 然 后 设置 给 对 应 的 属性 ， 而 且 都 是 new 出 来 的 XXXComposite 类 型 ， 这 种 类 型 在 分 析 HandlerMapping 中 


的 RequestCondition 时 已 经 见 到 过 了 ， 使 用 的 是 责任 链 模 式 ， 它 自己 并 不 实际 干 活 ， 而 是 封装 了 多 个 别 的 组 件 ， 干 活 时 交 给 别 的 组 件 ， 主 要 作用 是 方便 调用 。getDefaultXXX 方 法 稍 后 分 析 ， 下 面 先 来 看 一 
下 initControllerAdviceCache 是 怎么 工作 的 : 


// org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerRdapter 
private void initControllerAdviceCache() { 
if (getApplicationContext() 一 null) { 


return; 
} 
if (logger.isInfoPnabled()) { 
Jogger.info ("Looking for @ControllerAdvice: " + getApplicationContext () ) 7 


} 
// 获取 到 所 有 注释 了 @ControllerAdvice 的 bean 
List<ControllerAdviceBean> beans = ControllerAdviceBean.findAnnotatedBeans (getApplicationContext ()); 
// 根据 Order 排 序 
Collections.sort (beans, new OrderComparator () ) 7 
List<Object> responseBodyAdviceBeans = new ArrayList<Object>(); 
for (ControllerAdviceBean bean : beans) { 
// 查找 注释 了 @ModelAttribute 而 且 没 注释 @ RequestMapping 的 方法 
Set<Method> attrMethods = HandlerMethodSelector.selectMethods (bean.getBeanType (), MODEL ATTRIBUTE METHODS); 
if (!attrMethods.isEmpty()) { i x 
this.modelAttributeAdviceCache.put (bean, attrMethods); 
logger.info ("Detected @ModelAttribute methods in " + bean); 


} 
// 查找 注释 了 @InitBinder 的 方法 
Set<Method> binderMethods = HandlerMethodSelector.selectMethods (bean.getBeanType (), INIT BINDER METHODS); 
if (!binderMethods.isEmpty()) { 
this.initBinderAdviceCache.put (bean, binderMethods); 
logger.info ("Detected @InitBinder methods in " + bean); 


i 

// 查找 实现 了 ResponseBodyAdvice 接 口 的 类 

if (ResponseBodyAdvice.class.isAssignableFrom(bean.getBeanType())) { 
responseBodyAdviceBeans .add (bean); 
logger.info ("Detected ResponseBodyAdvice bean in " + bean); 


} 
// 将 查找 到 的 实现 了 ResponseBodyAdvice 接 口 的 类 从 前 面 添加 到 responseBodyAdvice 属 性 
if (!responseBodyAdviceBeans.isEmpty()) { 
this.responseBodyAdvice.addAll (0, responseBodyAdviceBeans); 
} 


这 里 首先 通过 ControllerAdviceBean.findAnnotatedBeans (getApplicationContext()) 拿 到 容器 中 所 有 注释 了 @ControllerAdvice 的 bean， 并 根据 Order 排 了 序 ， 然 后 使 


for 循 环 遍历 ， 找 到 每 个 


bean 里 相应 的 方法 (或 bean 自 身 ) 设置 到 相应 的 属性 。 查 找 @ModelAttribute 和 @InitBinder 注 释 方 法 使 用 的 是 HandlerMethodSelector.selectMethods， 这 种 方法 前 面 已 经 介绍 过 了 ， 它 是 根据 第 二 个 
参数 Filter 来 选择 的 ， 只 不 过 这 里 的 Filter 单 独 定义 成 了 静态 变量 INIT_BINDER_METHODS 和 MODEL ATTRIBUTE_METHODS， 它 们 分 别 表 示 查 找 注释 了 @InitBinder 的 方法 和 注释 了 @ModelAttribute 而 


且 没 注释 @RequestMapping 的 方法 (同时 注释 了 @RequestMapping 的 方法 只 是 将 返 


回 


值 设置 到 M ode| 而 不 是 作为 View 使 用 了 ， 但 不 会 提前 执行 ) ， 代 码 如 下 : 


// org.springframework.web.servlet .mve.method.annotation.RequestMappingHandlerAdapter 
public static final MethodFilter INIT BINDER METHODS = new MethodFilter() { 


QOverride 
public boolean matches (Method method) { 
return AnnotationUtils.findAnnotation (method, InitBinder.class) != null; 


} 
}; 
public static final MethodFilter MODEL ATTRIBUTE METHODS = new MethodFilter() { 
QOverride 
public boolean matches (Method method) { 
return ((AnnotationUtils.findAnnotation (method,RequestMapping.class)== null) && 
(AnnotationUtils.findAnnotation (method, ModelAttribute.class) != null)); 


}; 


实现 了 ResponseBodyAdvice 接 口 的 类 并 没有 在 for 循 环 里 直接 添加 到 responseBody-Advice 属 性 中 ， 而 是 先 将 它们 保存 到 responseBodyAdviceBeans 临 时 变量 里 ， 最 后 再 添加 到 


responseBodyAdvice 里 的 ， 添 加 的 代码 是 this.responseBodyAdvice.addAll (0,responseBody-AdviceBeans) ， 这 么 做 的 目的 就 是 要 把 这 里 找到 的 ResponseBodyAdvice 放 在 最 前 


回 


ResponseBodyAdvice 的 实现 类 有 两 种 注册 方法 ， 一 种 是 直接 注册 到 RequestMapping-HandlerAdapter， 另 外 一 种 是 通过 @ControllerAdvice 注 释 ， 让 Spring MVC 自 己 找到 并 注册 ， 从 这 里 可 以 看 到 通 


过 @ControllerAdvice 注 释 注册 的 优先 级 更 高 。 


说 完 initControllerAdviceCache， 再 返回 去 看 一 下 那 三 个 getDefaultXXX 方 法 ， 这 三 个 方法 非常 类 似 ， 下 面 以 getDefaultArgumentResolvers 为 例 来 进行 分 析 ， 这 个 方法 用 来 设置 argumentResolvers 


属性 ， 这 是 一 个 非常 核心 的 属性 ， 后 面 要 分 析 的 很 多 组 件 都 和 这 个 属性 有 关系 。 代 码 如 下 : 


// org.springframework.web.servlet .mve.method.annotation.RequestMappingHandlerAdapter 
private List<HandlerMethodArgumentResolver> getDefaultArgumentResolvers() { 
List<HandlerMethodArgumentResolver> resolvers = new ArrayList<HandlerMethodArgumentResolver> (); 
// 添加 按 注释 解析 参数 的 解析 器 
resolvers.add (new RequestParamMethodArgumentResolver (getBeanFactory(), false)); 
resolvers.add (new RequestParamMapMethodArgumentResolver ()); 
resolvers.add (new PathVariableMethodArgumentResolver () ) 7 
resolvers.add (new PathVariableMapMethodArgumentResolver ()); 
resolvers.add (new MatrixVariableMethodArgumentResolver () ) 7 
resolvers.add (new MatrixVariableMapMethodArgumentResolver ())，; 
resolvers.add (new ServletModelAttributeMethodProcessor (false)); 
resolvers.add (new RequestResponseBodyMethodProcessor (getMessageConverters () 
resolvers.add (new RequestPartMethodArgumentResolver (getMessageConverters () ) 
resolvers.add (new RequestHeaderMethodArgumentResolver (getBeanFactory())); 
resolvers.add (new RequestHeaderMapMethodArgumentResolver ()); 
resolvers.add (new ServletCookieValueMethodArgumentResolver (getBeanFactory())); 
resolvers.add (new ExpressionValueMethodArgumentResolver (getBeanFactory ())); 
// 添加 按 类 型 解析 参数 的 解析 器 
resolvers.add (new ServletRequestMethodArgumentResolver () ) 7 
resolvers.add (new ServletResponseMethodArgumentResolver () ) 
resolvers.add (new HttpEntityMethodProcessor (getMessageConverters ())); 
resolvers.add (new RedirectAttributesMethodArgumentResolver ()); 
resolvers.add (new ModelMethodProcessor ()); 
( 
( 
( 


) 7 


) 
) 


resolvers.add (new MapMethodProcessor () ) 7 
resolvers.add (new ErrOrSMethodArgumentResolver () ) 7 
resolvers.add (new SessionStatusMethodArgumentResolver () ) 
resolvers.add (new UriComponentsBuilderMethodArgumentResolver () ) 7 
// 添加 自 定义 参数 解析 器 ， 主 要 用 于 解析 自 定义 类 型 
if (getCustomArgumentResolvers() != null) { 

resolvers.addAll (getCustomArgumentResolvers ()); 


} 

// 最 后 两 个 解析 器 可 以 解析 所 有 类 型 的 参数 

resolvers.add (new RequestParamMethodArgumentResolver (getBeanFactory(), true)); 
resolvers.add (new ServletModelAttributeMethodProcessor (true)); 

return resolvers; 


通过 注释 可 以 看 到 ， 这 里 的 解析 器 可 以 分 为 四 类 : 通过 注释 解析 的 解析 器 、 通 过 类 型 解析 的 解析 器 、 自 定义 的 解析 器 和 可 以 解析 所 有 类 型 的 解析 器 。 第 三 类 是 可 以 自己 定义 的 解析 器 ， 定 义 方法 是 自己 
按 要 求 写 个 resolver 然 后 通过 customArgumentResolvers 属 性 注册 到 RequestMappingHandlerAdapter。 需 要 注意 的 是 ， 自 定义 的 解析 器 是 在 前 两 种 类 型 的 解析 器 都 无 法 解析 的 时 候 才 会 使 用 到 ， 这 个 顺 
序 无 法 改变 ! 所 以 如 果 要 想 自 己 写 一 个 解析 器 来 解析 @PathVariable 注 释 的 PathVariable 类 型 的 参数 ， 是 无 法 实现 的 ， 即 使 写 出 来 并 注册 到 RequestMappingHandlerAdapter 上 面 也 不 会 被 调用 。Spring 


MVC 自 己 定义 的 解析 器 的 顺序 也 是 固定 的 ， 不 可 以 改变 。 


RequestMappingHandlerAdapter 的 创建 就 这 些 内 容 ， 如 果 理 解 了 那 几 个 组 件 的 作用 就 会 觉得 非常 简单 。 


13.2.2 ”RequestMappingHandlerAdapter 之 用 


RequestMappingHandlerAdapter 处 理 请 求 的 入 口 方法 是 handlelnternal， 代 码 如 下 : 


// org.springframework.web.servlet .mve.method.annotation.RequestMappingHandlerAdapter 
protected ModelAndView handleInternal (HttpServletRequest request,HttpServletResponse response, HandlerMethod handlerMethod) throws Exception { 


// 判断 Handler 是 否 有 QSessionAttributes 注 释 的 参数 


if (getSessionAttributesHandler (handlerMethod) .hasSessionAttributes()) { 
checkAndPrepare (request, response, this.cacheSecondsForSessionAttributeHandlers, true); 


} else { 
checkAndPrepare (request, response, true); 
} 
if (this.synchronizeOnSession) { 
HttpSession session = request.getSession (false); 
if (session != null) { 
Object mutex = WebUtils.getSessionMutex (session); 
synchronized (mutex) { 


return invokeHandleMethod (request, response, handlerMethod); 


} 
} 
} 
return invokeHandleMethod (request, response, handlerMethod); 


} 


这 里 面 真正 起 作 
session 同 步 ， 否 则 不 同步 。 下 面 详细 分 析 这 两 个 方法 。 


checkAndPrepare 方 法 


checkAndPrepare 方 法 在 父 类 WebContentGenerator 中 定义 ， 主 要 做 了 三 件 事 。 


第 一 件 事 是 根据 supportedMethods 属 性 对 request 的 类 型 是 否 支持 进行 判断 。supported-Methods 属 性 | 


来 保存 所 有 支持 的 request 类 型 ， 如 果 为 空 则 不 检查 ， 否 则 


的 代码 只 有 两 句 ， 也 是 两 个 方法 : checkAndPrepare 和 invokeHandle-Method。 后 者 具体 执行 请 求 的 处 理 ， 有 两 种 运行 方式 ， 如 果 synchronizeOnSession 属 性 设置 为 true， 则 对 


它 检查 是 否 支持 当前 请 求 的 类 


型 ， 如 果 不 支持 则 抛 出 异常 。supportedMethods 默 认为 空 ， 可 以 在 注册 RequestMappingHandlerAdapter 的 时 候 对 其 进行 设置 ， 而 且 如 果 在 构造 方法 中 给 restrict-DefaultSupportedMethods 传 入 
true，supportedMethods 会 默认 设置 Get、Head、Post 三 个 值 ， 也 就 是 只 支持 这 三 种 类 型 request 请 求 ，WebContentGenerator 的 构造 方法 如 下 : 


// org.spPringframework.web.serVlet.supPort.WebContentGenerator 
public WebContentGenerator (boolean restrictDefaultSupportedMethods) 
if (restrictDefaultSupportedMethods) { 
this.supportedMethods = new HashSet<String>(4); 
this.supportedMethods .add (METHOD GET); 
this.supportedMethods .add (METHOD HEAD); 
this.supportedMethods .add (METHOD POST) : 


{ 


不 过 在 RequestMappingHandlerAdapter 的 父 类 AbstractHandlerMethodAdapter 中 直接 传 入 了 false， 所 以 如 果 不 给 supportedMethods 设 置 值 ， 那 么 它 应 该 为 空 ， 也 就 是 默认 不 检查 请 求 的 类 型 。 


第 二 件 事 是 如 果 requireSession 为 true， 则 通过 request.getSession (false) 检查 session 是 否 存 在 ， 如 果 不 存 在 则 抛 出 异常 ， 不 过 requireSession 的 默认 值 为 false， 所 以 默认 也 不 检查 。 


第 三 件 事 是 给 response 设 置 缓存 过 期 时 间 。checkAndPrepare 代 码 如 下 : 


// org.springframework.web.servlet.support .WebContentGenerator 
protected final void checkAndPrepare( 


HttpServletRequest request, HttpServletResponse response, int cacheSeconds, boolean lastModified) 


throws ServletException { 
// 检查 请 求 的 类 型 是 否 支持 
String method = request.getMethod(); 


if (this.supportedMethods != null && !this.supportedMethods.contains (method)) { 


throw new HttpRequestMethodNotSupportedException( 


method, StringUtils.tostringArray (this.supportedMethods)); 


} 
// 如 果 session 是 必须 存在 的 ， 判 断 session 实 际 是 否 存在 
if (this.requireSession) { 

if (request.getSession(false) 一 null) { 


throw new HttpSessionRequiredException ("Pre-existing session required but none found"); 


} 
} 
// 给 response 设 置 缓 存 过 期 时 间 
applyCacheSeconds (response, cacheSeconds, lastModified); 


在 checkAndPrepare 方 法 调 


际 是 检查 注释 里 的 name 和 types 参 数 ， 不 过 只 要 有 注释 就 应 该 有 参数 ， 否 则 就 没有 


解 起 来 却 有 点 难度 ， 是 因为 里 面 使 用 到 了 两 个 我 们 不 熟悉 的 组 件 ， 还 有 一 个 


容易 区 分 了 。 另 外 还 要 知道 SessionAttributeStore 并 不 是 | 


许 更 合适 一 些 ， 只 有 知道 了 这 一 点 才能 想 明 白 所 有 的 SessionAttributesHandler 


于 处 理 @SessionAttributes 注 释 的 。getSessionAttributesHandler 代 码 如 下 : 


前 还 有 一 个 if 条 件 : getSessionAttributesHandler (handler-Method) .hasSessionAttributes()， 这 个 条 件 的 意思 是 检查 处 理 器 类 是 否 有 @SessionAttributes 注 释 ( 实 
了 ， 所 以 相当 于 检查 有 没有 @ SessionAttributes 注 释 ) 。 
来 做 缓存 的 属性 ， 而 且 这 个 属性 和 其 中 的 SessionAttributesHandler 组 件 都 
们 只 需要 知道 handlerType 在 缓存 的 属性 中 是 用 作 key， 为 了 能 找到 相应 的 SessionAttributesHandler， 而 用 在 SessionAttributesHandler 中 主要 是 为 了 获取 注释 里 面 的 value 和 types 的 值 就 可 以 了 ， 这 样 就 
来 保存 SessionAttribute 参 数 的 容器 ， 而 是 保存 SessionAttribute 参 数 的 工 . 


其 中 的 getSessionAttributesHandler 方 法 虽然 代码 不 多 ， 但 理 
到 了 handlerType， 这 就 更 容易 混淆 了 。 我 


， 如 果 只 看 名 字 很 容易 造成 误解 ， 叫 SessionAttributeStoreTools 也 


了 同一 个 SessionAttributeStore 的 原因 ， 知 道 了 这 些 ， 这 个 方法 也 就 容易 理解 了 ， 这 两 个 组 件 后 面 再 详细 介绍 ， 它 们 都 是 


// org.springframework.web.servlet .mvce.method.annotation.RequestMappingHandlerAdapter 
Private SessionAttributesHandler getSessionAttributesHandler (HandlerMethod handlerMethod) { 


Class<?> handlerType = handlerMethod.getBeanType (); 


SessionAttributesHandler sessionAttrHandler=this.sessionAttributesHandlerCache.get (handlerType); 


// 第 一 次 使 用 后 保存 到 缓存 中 ， 之 后 再 使 用 时 直接 从 缓存 中 获取 
if (sessionAttrHandler == null) { 
synchronized (this.sessionAttributesHandlerCache) { 


sessionAttrHandler=this.sessionAttributesHandlerCache.get (handlerType); 


if (sessionAttrHandler == null) { 


sessionAttrHandler=new SessionAttributesHandler (handlerType, sessionAttributeStore); 
this.sessionAttributesHandlerCache.put (handlerType, sessionAttrHandler); 


} 
} 


return sessionAttrHandler; 


说 完了 getSessionAttributesHandler， 接 着 看 前 面 的 if 条 件 ， 通 过 检查 后 ， 如 果 有 @Session-Attributes 注 释 则 调 


checkAndPrepare (request, response, this.cacheSecondsForSessionAttributeHandlers，true) ,否则 调 


this.cacheSecondsForSessionAttributeHandlers 的 默认 值 为 0， 而 后 面 的 方法 在 内 部 又 调 


上 默认 是 -1。 也 就 是 说 在 默认 的 配置 下 如 果 存 在 @SessionAttributes 注 释 则 调 
1, lastModified) 。 


checkAndPrepare (request, response, 0，lastModified) ， 否 则 调 


checkAndPrepare (request，response，true) ， 参 数 


了 checkAnd-Prepare (request, response, this.cacheSeconds, lastModified) ，this.cacheSeconds 参 数 


checkAndPrepare (request，response，- 


通过 前 面 的 分 析 知道 ，checkAndPrepare 方 法 在 默认 的 配置 下 只 执行 给 response 设 置 缓存 过 期 时 间 的 任务 ， 设 置 的 方法 是 applyCacheSeconds， 代 码 如 下 : 


// org.springframework.web.servlet.support .WebContentGenerator 
protected final void applyCacheSeconds (HttpServletResponse response, 
if (seconds > 0) { 


int seconds, boolean mustRevalidate) { 


CacheForSeconds (response, seconds, mustRevalidate); 
} else if (seconds == 0) { 
preventCaching (response); 


} 


这 里 的 seconds 就 是 checkAndPrepare 的 第 三 个 参数 ， 也 就 是 0 和 -1 的 那个 参数 ， 从 代码 可 以 看 出 ， 如 果 为 -1 则 不 做 任何 事情 ， 如 果 等 于 0 则 调用 preventCaching 方 法 ， 如 果 大 于 0 则 调 
cacheForSeconds 方 法 。preventCaching 方 法 用 来 阻止 使 用 缓存 ，cacheForSeconds 方 法 给 缓存 设置 过 期 时 间 ， 代 码 如 下 : 


// org.springframework.web.serVlet.supPort.WebContentGenerator 
protected final void preventCaching (HttpServletResponse response) { 
response. setHeader (HEADER PRAGMA, "no-cache"); 
if (this.useExpiresHeader) { 
// HTTP 1.0 header 
response. setDateHeader (HEADER EXPIRES, 1L); 
} 
if (this.useCacheControlHeader) { 
// HTTP 1.1 header: "no-cache" is the standard value, 
// "no-store" is necessary to prevent caching on FireFox.response. 
// setHeader (HEADER CACHE CONTROL, "no-cache"); 
if (this.useCacheControlNoStore) { 
response.addHeader (HEADER CACHE CONTROL, "no-store"); 
} 
} 
} 
protected final void cacheForSeconds (HttpServletResponse response,intseconds, boolean mustRevalidate) { 
if (this.useExpiresHeader) { 
// HTTP 1.0 header 
response.setDateHeader (HEADER EXPIRES, System.currentTimeMillis()+seconds*1000L); 


if (this.useCacheControlHeader) { 
// HTTP 1.1 header 


String headerValue = "max-age=" + seconds; 
if (mustRevalidate || this.alwaysMustRevalidate) { 
headerValue += ", must-revalidate"; 


} 
response.setHeader (HEADER CACHE CONTROL, headerValue); 


这 里 其 实 就 是 对 Response 的 Header 进 行 了 相应 的 设置 。 


说 了 这 么 多 ， 其 实 这 段 代码 的 功能 非常 简单 : (默认 配置 的 情况 下 ) 如 果 有 @Session-Attribute 注 释 则 阻止 使 用 缓存 ， 否 则 什么 也 不 做 。 另 外 还 可 以 看 到 一 点 : cacheSecondsFor- 
SessionAttributeHandlers 和 cacheSeconds 参 数 其 实 与 Session 的 超时 并 没有 关系 ， 而 是 用 于 设置 response 缓 存 相关 的 Header 参 数 。 


多 知道 点 
@SessionAttribute 是 什么 以 及 怎么 用 


@SessionAttribute 注 释 用 在 处 理 器 类 上 ， 用 于 在 多 个 请 求 之 间 传 递 参 数 ， 类 似 于 Session 的 Attribute， 但 不 完全 一 样 。 一 般 来 说 @SessionAttribute 设 置 的 参数 只 用 于 暂时 的 传递 ， 而 不 是 长 期 的 保存 ， 像 身份 


验证 信息 等 需要 长 期 保存 的 参数 还 是 应 该 使 用 Session#setAttribute 设 置 到 Session 中 。 


通过 (COSessionAttribute 注 释 设 置 的 参数 有 3 类 用 法 : 四 在 视图 中 通过 request.getAttribute 或 session.getAttribute 获 取 ; 加 在 后 面 请 求 返回 的 视图 中 通过 session.getAttribute 或 者 从 Model 中 获取 ; (加 自动 将 参数 设 
置 到 后 面 请 求 所 对 应 处 理 器 的 Model 类 型 参数 或 者 有 (@ModelAttribute 注 释 的 参数 里 面 。 


说 完了 用 法 ， 再 说 一 下 怎么 设置 。 将 一 个 参数 设置 到 SessionAttribute 中 需要 满足 两 个 条 件 : 外 在 @SessionAttribute 注 释 中 设置 了 参数 的 名 字 或 者 类 型 ;加 在 处 理 器 中 将 参数 设置 到 了 model 中 。 


(@SessionAttribute 用 完 后 可 以 调用 SessionStatus.setComplete 来 清除 。 这 种 方法 只 是 清除 SessionAttribute 里 的 参数 ， 而 不 会 影响 Session 中 的 参数 。SessionStatus 可 以 定义 在 处 理 器 方法 的 参数 
中 ，RequestMappingHandlerAdapter 会 自动 将 其 设置 进去 。 


我 们 来 看 个 例子 。 


QController 
@RequestMapping ("/book") 
@SessionAttributes (value={"book", "description"},types={Double.class}) 
public class BookController { 
private final Log logger = LogFactory.getLog (BookController.class); 
@RequestMapping ("/index") 
public String index (Model model) throws Exception { 
model .addAttribute ("book"， "金刚 经 "); 
model .addAttribute ("dqescription"，" 般 若 系列 重要 经 典 ") 7 
model .addAttribute ("price", new Double("999.99")); 
return "redirect:get"; 
} 
@RequestMapping ("/get") 
public String getBySessionAttributes (@ModelAttribute 
logger .info ("==———————=getBySessionAttributes=== 
logger.info("get by QModelAttribute:"+book); 
logger.info ("get by ModelMap:"+tmodel .get ("book")+": 
SessionStatus .SetComplete () 7 
return "redirect:complete"; 


"book") String book, ModelMap model, SessionStatus sessionStatus) throws Exception { 


+model .get ("description")+", "+model .get ("price")); 


} 

@RequestMapping ("/complete") 

public String afterComplete (ModelMap model) throws Exception { 
logger .info ("=== —=afterComplete=—————=—=") 
logger .info (model .get ("book")+": "+model .get ("description")+", "+model .get ("price")); 
return "index"; 


这 个 处 理 器 类 注释 了 (@SessionAttributes， 它 将 会 对 book、description 为 名 称 的 参数 和 所 有 Double 类 型 的 参数 使 用 SessionAttributes 来 缓存 ， 所 以 在 /book/index 请 求 中 将 book、description 和 price 三 个 参数 设置 
到 Model 的 同时 也 会 自动 设置 到 SessionAttributes 中 ， 这 样 在 redirect 后 的 getBySessionAttributes 处 理 器 方法 中 就 可 以 获取 到 ， 获 取 的 方法 使 用 了 @ModelAttribute 和 ModelMap 两 种 方式 ， 使 用 完 后 通过 调用 
sessionStatus.setCompblete0 通知 SessionAtttibutes 已 经 使 用 完了 ， 这 时 参数 就 从 缓存 中 删除 了 ， 所 以 在 再 次 redirect 后 的 afterComplete 处 理 器 方法 里 面 就 获取 不 到 了 。 日 志 打 印 如 下 : 


========-=getBySessionAttributes====-======== 
get by @ModelAttribute: 人 金刚 经 
get by ModelMap: 人 金刚 经 ; 般若 系列 重要 经 典 ，999.99 


null, null 


@SessionAttribute 合 适 的 使 用 将 会 为 程序 编写 带 来 很 大 方便 ， 比 如 ， 企 业 业 务 系统 里 面 常 用 到 的 根据 查询 条 件 参 数 查询 记录 而 且 结 果 要 分 页 显示 的 情况 ， 这 时 候 每 翻 一 页 都 需要 传递 一 次 参数 ， 如 果 将 查 
询 参 数 保存 到 SessionAttribute 里 面 就 非常 方便 了 。 再 如 ， 很 多 查询 页 面 都 有 下 拉 列 表 ， 而 且 在 业务 系统 里 这 些 列表 的 值 很 多 时 候 都 是 可 变 的 ， 是 保存 在 数据 库 里 面 的 ， 使 用 时 需要 从 数据 库 里 获取 ， 如 果 将 它 
们 保存 到 SessionAttribute 里 会 非常 方便 ， 那 样 不 但 不 需要 每 次 使 用 时 都 查询 了 ， 而 且 连 处 理 器 里 设置 到 model 的 过 程 都 不 需要 了 (但 @SessionAttribute 注 释 不 能 少 ) ， 直 接 在 View 里 使 用 就 行 ! 


通过 SessionAttfibute 保 存 下 拉 列 表 参 数 的 功能 也 可 以 自己 使 用 缓存 技术 将 它们 缓存 起 来 ， 但 是 相对 来 说 通过 SessionAtttibute 保 存 的 方式 更 好 ， 首 先 使 用 简单 了 ， 其 次 设置 到 SessionAttfibute 里 的 参数 可 以 


方便 地 根据 用 户 的 权限 对 不 同 的 用 户 设置 不 同 的 值 ， 比 如 ， 不 同 的 用 户 可 以 查看 的 部 门 可 能 不 同 ， 对 某 个 产品 的 操作 权限 也 可 能 不 一 样 等 ， 这 时 候 如 果 保存 到 我 们 自己 的 缓存 中 还 是 比较 麻烦 的 ， 不 过 
SessionAtttibute 可 以 和 我 们 自己 的 缓存 配合 一 起 使 用 ， 比 如 ， 将 全 部 数据 缓存 到 我 们 自己 的 缓存 中 ， 用 户 需要 的 时 候 从 我 们 的 缓存 中 筛选 出 对 应 的 数据 然后 放 到 SessionAttribute 中 ， 这 样 就 不 需要 每 次 都 查 数 
据 库 了 ， 在 数据 发 生 改 变 的 时 候 再 更 新 我 们 的 缓存 并 让 SessionAttribute 失 效 就 可 以 了 。 


invokeHandleMethod 方 法 


invokeHandleMethod 方 法 非常 重要 ， 它 具体 执行 请 求 的 处 理 ， 


代码 如 下 : 


//org.springframework.web.servlet .mvce.method.annotation.RequestMappingHandlerAdapter 
private ModelAndView invokeHandleMethod (HttpServletRequest request, 

HttpServletResponse response, HandlerMethod handlerMethod) throws Exception { 
ServletWebRequest webRequest = new ServletWebRequest (request, response); 
WebDataBinderFactory binderFactory = getDataBinderFactory (handlerMethod); 
ModelFactory modelFactory = getModelFactory (handlerMethod, binderFactory); 
ServletInvocableHandlerMethod requestMappingMethod = createRequestMappingMethod (handlerMethod, binderFactory); 
ModelAndViewContainer mavContainer = new ModelAndViewContainer () 7 
mavContainer.addAllAttributes (RequestContextUtils.getInputFlashMap (request)); 
modelFactory.initModel (webRequest, mavContainer, requestMappingMethod); 
mavContainer.setIgnoreDefaultModelOnRedirect (this.ignoreDefaultModelOnRedirect); 
AsyncWebRequest asyncWebRequest = WebAsyncUtils.createAsyncWebRequest (request, response); 
asyncWebRequest .setTimeout (this.asyncRequestTimeout); 
final WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager (request); 
asyncManager .setTaskExecutor (this.taskExecutor); 
asyncManager .setAsyncWebRequest (asyncWebRequest); 
asyncManager .registerCallableInterceptors (this.callableInterceptors); 
asyncManager .registerDeferredResultInterceptors (this.deferredResultInterceptors); 
if (asyncManager.hasConcurrentResult()) { 

Object result = asyncManager.getConcurrentResult (); 

mavContainer= (ModelAndViewContainer)asyncManager .getConcurrentResultContext () [0]; 

asyncManager.clearConcurrentResult (); 

if (logger.isDebugEnabled()) { 

logger.debug ("Found concurrent result value [" + result + "]"); 


requestMappingMethod = requestMappingMethod.wrapConcurrentResult (result); 
} 
requestMappingMethod.invokeAndHandle (webRequest, mavContainer); 
if (asyncManager.isConcurrentHandlingStarted()) { 
return null; 
} 


return getModelAndView (mavContainer, modelFactory, webRequest); 


在 invokeHandleMethod 方 法 中 首先 使 用 request 和 response 创 建 了 ServletWebRequest 类 型 的 webRequest， 在 ArgumentResolver 解 析 参 数 时 使 用 的 request 就 是 这 个 webRequest， 当 然 如 果 我 们 
的 处 理 器 需要 HttpServletRequest 类 型 的 参数 ，ArgumentResolver 会 给 我 们 设置 原始 的 request。 


接着 对 WebDataBinderFactory、ModelFactory、ServletInvocableHandlerMethod 这 三 个 类 型 的 变量 进行 了 定义 和 初始 化 ， 下 面 先 分 别 介绍 一 下 这 三 个 变量 。 


* WebDataBinderFactory 


WebDataBinderFactory 的 作用 从 名 字 就 可 以 看 出 是 用 来 创建 WebDataBinder 的 ，WebDataBinder 用 于 参数 绑 定 ， 主 要 功能 就 是 实现 参数 跟 String 之 间 的 类 型 转换 ，ArgumentResolver 在 进行 参数 解 
析 的 过 程 中 会 用 到 WebDataBinder， 另 外 ModelFactory 在 更 新 Model 时 也 会 用 到 它 。 


WebDataBinderFactory 的 创建 过 程 就 是 将 符合 条 件 的 注释 了 @InitBinder 的 方法 找 出 来 ， 并 使 用 它们 新 建 出 ServletRequestDataBinderFactory 类 型 的 WebDataBinderFactory。 这 里 的 InitBinder 方 
法 包括 两 部 分 : 一 部 分 是 注释 了 @ControllerAdvice 的 并 且 符 合 要 求 的 全 局 处 理 器 里 面 的 InitBinder 方 法 ; 第 二 部 分 就 是 处 理 器 自身 的 InitBinder 方 法 ， 添 加 的 顺序 是 先 添 加 全 局 的 后 添加 自身 的 。 第 二 类 
InitBinder 方 法 会 在 第 一 次 调用 后 保存 到 缓存 中 ， 以 后 直接 从 缓存 获取 就 可 以 了 。 查 找 注释 了 @InitBinder 方 法 的 方法 和 以 前 一 样 ， 使 用 HandlerMethodSelector.selectMethods 来 找 ， 而 全 局 的 InitBinder 
方法 在 创建 RequestMappingHandlerAdapter 的 时 候 已 经 设置 到 缓存 中 了 。WebDataBinderFactory 创 建 代码 如 下 : 


//org.springframework.web.servlet .mvce.method.annotation.RequestMappingHandlerAdapter 
private WebDataBinderFactory getDataBinderFactory (HandlerMethod handlerMethod) throws Exception { 
Class<?> handlerType = handlerMethod.getBeanType (); 
// 检查 当前 Handler 中 的 InitBinder 方 法 是 否 已 经 存在 缓存 中 
Set<Method> methods = this.initBinderCache.get (handlerType); 
// 如 果 没 有 则 查找 并 设置 到 缓存 中 
if (methods == null) { 
methods = HandlerMethodSelector.selectMethods (handlerType, INIT BINDER METHODS); 
this.initBinderCache.put (handlerType, methods); 


} 
// 定义 保存 InitBinder 方 法 的 临时 变量 
List<InvocableHandlerMethod> initBinderMethods = new ArrayList<InvocableHandlerMethod>(); 
// 将 所 有 符合 条 件 的 全 局 InitBinder 方 法 添加 到 initBinderMethods 
for (Entry<ControllerAdviceBean, Set<Method>>entry:this.initBinderAdviceCache.entrySet ()) { 
if (entry.getKey () .isApplicableToBeanType (handlerType)) { 
Object bean = entry.getKey () .resolveBean () 7 
for (Method method : entry.getValue()) { 
initBinderMethods .add (createInitBinderMethod (bean, method)); 
} 
} 


EF 
// 将 当前 Handler 中 的 InitBinder 方 法 添加 到 initBinderMethods 
for (Method method : methods) { 
Object bean = handlerMethod.getBean () 7 
initBinderMethods .add (createInitBinderMethod (bean, method)); 


} 
// 创建 DataBinderFactory 并 返回 
return createDataBinderFactory (initBinderMethods); 


protected InitBinderDataBinderFactory createDataBinderFactory (List<InvocableHandlerMethod> binderMethods) throws Exception { 
return new ServletRequestDataBinderFactory (binderMethods, getWebBindingInitializer()); 
} 


通过 注释 大 家 应 该 就 很 容易 理解 了 。 需 要 注意 的 是 HandlerMethodSelector.selectMethods 的 返回 值 是 一 个 Set， 如 果 没 找到 相应 的 方法 会 返回 一 个 空 Set 而 不 是 null， 所 以 即使 没 找到 InitBinder 方 
法 ，initBinderCache 也 会 为 当前 的 Handler 设 置 一 个 空 Set， 这 样 就 可 以 用 initBinderCache.get (handlerType) 是 否 为 null 区 分 开 没有 调用 过 的 处 理 器 和 调用 过 但 没有 InitBinder 方 法 的 处 理 器 。 
WebDataBinderFactory 主 要 和 相应 的 InitBinder 方 法 相关 联 。 


* ModelFactory 


ModelFactory 是 用 来 处 理 Model 的 ， 主 要 包含 两 个 功能 : @ 在 处 理 器 具体 处 理 之 前 对 Model 进 行 初始 化 ; @ 在 处 理 完 请 求 后 对 Model 参 数 进行 更 新 。 


给 Model 初 始 化 具体 包括 三 部 分 内 容 : @ 将 原来 的 SessionAttributes 中 的 值 设 置 到 Model; @ 执 行 相应 注释 了 @ModelAttribute 的 方法 并 将 其 值 设置 到 Mode; @ 处 理 器 中 注释 了 @ModelAttribute 
的 参数 如 果 同时 在 SessionAttributes 中 也 配置 了 ， 而 且 在 mavContainer 中 还 没有 值 则 从 全 部 SessionAttributes (可 能 是 其 他 处 理 器 设置 的 值 ) 中 查找 出 并 设置 进去 。 


对 Model 更 新 是 先 对 SessionAttributes 进 行 设置 ， 设 置 规则 是 如 果 处 理 器 里 调用 了 SessionStatus#setComplete 则 将 SessionAttributes 清 空 ， 否 则 将 mavContainer 的 defaultModel (可 以 理解 为 
Model， 后 面 ModelAndViewContainer 中 会 详细 讲解 ) 中 相应 的 参数 设置 到 SessionAttributes 中 ， 然 后 按 需 要 给 Model 设 置 参数 对 应 的 BindingResult。 


从 这 里 可 以 看 出 调用 SessionStatus#setComplete 清 空 SessionAttributes 是 在 整个 处 理 执行 完 以 后 才 执行 的 ， 也 就 是 说 这 条 语句 在 处 理 器 中 的 位 置 并 不 重要 ， 放 在 处 理 器 的 开头 或 者 结尾 都 不 会 影响 当 


前 处 理 器 对 SessionAttributes 的 使 用 。 


ModelFactory 的 创建 过 程 在 getModelFactory 方 法 中 ， 代 码 如 下 : 


// org.springframework.web.servlet .mvce.method.annotation.RequestMappingHandlerAdapter 
private ModelFactory getModelFactory (HandlerMethod handlerMethod, WebDataBinderFactory binderFactory) { 

// 获取 SessionAttributesHandler 
SessionAttributesHandler sessionAttrHandler = getSessionAttributesHandler (handlerMethod) 
// 获取 处 理 器 类 的 类 型 
Class<?> handlerType = handlerMethod.getBeanType (); 
// 获取 处 理 器 类 中 注释 了 @ModelAttribute 而 且 没 有 注释 8RequestMapping 的 类 型 ， 第 一 次 获取 后 添加 到 缓存 ， 以 后 直接 从 缓存 中 获取 
Set<Method> methods = this.modelAttributeCache.get (handlerType); 
if (methods == null) { 

methods = HandlerMethodSelector.selectMethods (handlerType, MODEL ATTRIBUTE METHODS); 

this.modelAttributeCache.put (handlerType, methods); 
} 
List<InvocableHandlerMethod>attrMethods=new ArrayList<InvocableHandlerMethod> () 7 
// 先 添加 全 局 @ModelAttribute 方 法 ， 后 添加 当前 处 理 器 定义 的 @ModelAttribute 方 法 
for (Entry<ControllerAdviceBean, Set<Method>>entry:this.modelAttributeAdviceCache.entrySet ()) { 

if (entry.getKey () .isApplicableToBeanType (handlerType)) { 

Object bean = entry.getKey () .resolveBean () 7 
for (Method method : entry.getValue()) { 
attrMethods.add (createModelAttributeMethod (binderFactory, bean, method)); 
} 

} 
} 
for (Method method : methods) { 

Object bean = handlerMethod.getBean () 7 

attrMethods.add (createModelAttributeMethod (binderFactory, bean, method)); 


} 
// 新 建 ModelFactory 
return new ModelFactory (attrMethods, binderFactory, sessionAttrHandler); 


从 最 后 一 句 新 建 ModelFactory 中 可 以 看 出 主要 使 用 了 三 个 参数 ， 第 一 个 是 注释 了 @ModelAttribute 的 方法 ， 第 二 个 是 WebDataBinderFactory， 第 三 个 是 SessionAttributesHandler。 


其 中 WebDataBinderFactory 使 用 的 就 是 上 面 创建 出 来 的 WebDataBinderFactory; Session-AttributesHandler 的 创建 方法 getSessionAttributesHandler 在 前 面 已 经 介绍 过 了 ; 注释 了 


@ModelAttribute 的 方法 分 两 部 分 : 一 部 分 是 注释 了 @ControllerAdvice 的 类 中 定义 的 全 局 的 @ModelAttribute 方 法 ; 另 一 部 分 是 当前 处 理 器 自身 的 @ModelAttribute 方 法 ， 添 加 规则 是 先 添加 全 局 的 后 
添加 自己 的 。 


' ServletInvocableHandlerMethod 


ServletlnvocableHandlerMethod 类 型 非常 重要 ， 它 继承 自 HandlerMethod， 并 且 可 以 直接 执行 。 实 际 请 求 的 处 理 就 是 通过 它 来 执行 的 ， 参 数 绑 定 、 处 理 请 求 以 及 返回 值 处 理 都 在 它 里 边 完成 ， 创 建 
方法 createRequestMappingMethod 代 码 如 下 : 


//org.springframework.web.servlet .mvc.method.annotation.RequestMappingHandlerAdapter 
private ServletInvocableHandlerMethod createRequestMappingMethod( 
HandlerMethod handlerMethod, WebDataBinderFactory binderFactory) { 
ServletInvocableHandlerMethod requestMethod; 
requestMethod = new ServletInvocableHandlerMethod (handlerMethod); 
requestMethod. setHandlerMethodArgumentResolvers (this.argumentResolvers); 
requestMethod.setHandlerMethodReturnValueHandlers (this.returnValueHandlers); 
requestMethod. setDataBinderFactory (binderFactory); 
requestMethod.setParameterNameDiscoverer (this.parameterNameDiscoverer); 
return requestMethod; 


这 里 的 参加 过 程 非常 简单 ， 首 先 使 用 handlerMethod 新 建 类 ServletlnvocableHandlerMethod 类 ， 然 后 将 argumentResolvers、returnValueHandlers、binderFactory 和 
parameterNameDiscoverer 设 置 进去 就 完成 了 。 


这 三 个 变量 弄 明白 后 invokeHandleMethod 方 法 就 容易 理解 了 。 这 三 个 变量 创建 完 之 后 的 工作 还 有 三 步 (这 里 省 略 了 异步 处 理 ) : @@ 新 建 传递 参数 的 ModelAndViewContainer 容 器 ， 并 将 相应 参数 设 
置 到 其 Model 中 ; @ 执 行 请 求 ; @ 请 求 处 理 完 后 进行 一 些 后 置 处 理 。 


“ 新 建 ModelAndViewContainer 类 型 的 mavContainer 参 数 ， 用 于 保存 Model 和 View， 它 贯穿 于 整个 处 理 过 程 (注意 ， 在 处 理 请 求 时 使 用 的 并 不 是 ModelAndView) ， 然 后 对 mavContainer 进 行 了 设置 ， 主 要 包 


括 三 部 分 内 容 : 四 将 FlashMap 中 的 数据 设置 到 Model; @ 使 用 modelFactory 将 SessionAttributes 和 注释 了 @ModelAttribute 的 方法 的 参数 设置 到 Model; (3 根据 配置 对 ignoreDefaultModelOnRedirect 进 行 了 设置 ， 这 个 
参数 在 分 析 ModelAndViewContainer 的 时 候 再 详细 讲解 。 设 置 代 码 如 下 : 


//org.springframework.web.servlet .mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandleMethod 
ModelAndViewContainer mavContainer = new ModelAndViewContainer (); 

mavContainer.addAllAttributes (RequestContextUtils.getInputFlashMap (request)); 

modelFactory.initModel (webRequest, mavContainer, requestMappingMethod); 
mavContainer.setIgnoreDefaultModelOnRedirect (this.ignoreDefaultModelOnRedirect); 


到 这 里 传递 参数 的 容器 就 准备 好 了 。 设 置 完 mavContainer 后 又 做 了 一 些 异 步 处 理 的 相关 的 工作 ， 异 步 处 理 在 后 面 专门 讲解 。 


. 执行 请 求 ， 具 体 方法 是 直接 调用 ServletInvocableHandlerMethod 里 的 invokeAndHandle 方 法 执行 的 ， 代 码 如 下 : 


//org.springframework.web.servlet .mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandleMethod 
requestMappingMethod.invokeAndHandle (webRequest, mavContainer); 


ServletlnvocableHandlerMethod 的 invokeAndHandle 方 法 执行 请 求 的 具体 过 程 在 后 面 分 析 ServletlnvocableHandlerMethod 的 时 候 再 详细 讲解 。 


“ 处 理 完 请 求 后 的 后 置 处 理 ， 这 是 在 getModelAndView 方 法 中 处 理 的 。 一 共 做 了 三 件 事 : 四 调用 ModelFactory 的 updateModel 方 法 更 新 了 Model (包括 设置 了 SessionAttributes 和 给 Model 设 置 BindingResult) ; 


@ 回 根据 mavContainer 创 建 了 ModelAndView; ( 辐 如 果 mavContainet 里 的 model 是 RedirectAttributes 类 型 ， 则 将 其 值 设置 到 FlashMap。 代 码 如 下 : 


//org.springframework.web.servlet .mvc.method.annotation.RequestMappingHandlerAdapter. 
private ModelAndView getModelAndView (ModelAndViewContainer mavContainer, 
ModelFactory modelFactory, NativeWebRequest webRequest) throws Exception { 
modelFactory .updateModel (webRequest, mavContainer); 
if (mavContainer.isRequestHandled()) { 
return null; 
} 
ModelMap model = mavContainer.getModel (); 
ModelAndView mav = new ModelAndView (mavContainer.getViewName (), model); 
// 如 果 mavContainer 里 的 View 不 是 引用 ， 也 就 是 不 是 String 类 型 ， 则 设置 到 mv 中 
if (!mavContainer.isViewReference ()) { 
mav.setView( (View) mavContainer.getView()); 
} 
if (model instanceof RedirectAttributes) { 
Map<String, ?>flashAttributes=( (RedirectAttributes)model) .getFlashAttributes (); 
HttpServletRequest request = webRequest .getNativeRequest (HttpServletRequest.class); 
RequestContextUtils.getOutputFlashMap (request) .putAll (flashAttributes); 
} 


return mav; 


这 里 的 model 只 有 处 理 器 在 返 


可 redirect 类 型 的 视图 时 才 可 能 是 RedirectAttributes 类 型 ， 否 则 不 会 ; 


是 RedirectAttributes 类 型 ， 也 就 是 说 在 不 返回 redirect 类 型 视 | 


RedirectAttributes 设 置 了 变量 也 不 会 保存 到 FalseMap 中 ， 具 体 细节 介绍 ModelAndViewContainer 的 时 候 再 详细 分 析 。 


过 程 〈 


整个 RequestMappingHandlerAdapter 处 理 请 求 的 


但 .23 坤 化 


本 节 详 细 分 析 了 RequestMappingHandlerAdapter 自 身 的 结构 。 作 为 一 个 HandlerAdapter，RequestMappingHandlerAdapter 的 作 | 


类 型 ， 处 理 请 求 的 过 程 主要 分 为 三 步 : 绑 定 参数 、 执 行 请 求 和 处 理 返回 值 。 


所 绑 定 的 参数 的 来 源 有 6 个 地 方 : @request 中 相关 的 参数 ， 主 要 包括 url 中 的 参数 、post 过 来 的 参数 以 及 请 求 头 中 的 值 ; @cookie 中 的 参数 ; @session 中 的 参数 ; @ 设 置 到 FlashMap 中 的 参数 ， 这 种 主 
于 redirect 的 参数 传递 ; SessionAttributes 传 递 的 参数 ; @ 通 过 相应 的 注释 了 @ModelAttribute 的 方法 进 : 


的 处 理 器 中 即使 使 


后 再 返回 来 看 就 容易 理解 了 


自身 处 理 过 程 ， 不 包含 组 件 内 部 处 理 ) 就 分 析 完 了 ， 接 下 来 分 析 里 面 涉及 的 组 件 ， 在 将 这 些 组 件 全 部 分 析 完 成 


进行 设置 的 参数 。 前 三 类 参数 通过 request 管 理 ， 


就 是 使 


处 理 器 处 理 请 求 。 它 使 


的 处 理 器 是 HandlerMethod 


后 三 类 通过 Model 管 理 。 前 三 类 在 request 中 


获取 ， 不 需要 做 过 多 准备 工作 。 第 四 类 参数 是 直接 在 RequestMappingHandlerAdapter 中 进行 处 理 的 ， 在 请 求 前 将 之 前 保存 的 设置 到 model， 请 求 处 理 完成 后 如 果 需 要 则 将 model 中 的 值 设置 到 
FlashMap。 后 两 类 参数 使 用 ModelFactory 管 理 。 

准备 好 参数 源 后 使 用 ServletlnvocableHandlerMethod 组 件 具体 执 行 请 求 ， 其 中 包括 使 用 ArgumentResolver 解 析 参 数 、 执 行 请 求 、 使 用 ReturnValueHandler 处 理 返 回 值 等 内 容 ， 详 细 内 容 会 在 
ServletlnvocableHandlerMethod 中 具体 讲解 。 

ServletlnvocableHandlerMethod 执 行 完 请 求 处 理 后 还 有 一 些 扫 尾 工 作 ， 主 要 是 Model 中 参数 的 缓存 和 ModelAndView 的 创建 。 

整个 处 理 过 程 其 实 非 常 简单 ， 只 是 里 面 使 用 了 很 多 我 们 不 熟悉 的 组 件 ， 这 些 组 件 如 果 理 解 了 再 返回 来 看 就 简单 了 。 接 下 来 就 分 别 讲解 这 些 组 件 。 
13.3 ModelAndViewContainer 

ModelAndViewContainer 承 担 着 整个 请 求 过 程 中 数据 的 传递 工作 。 它 除了 保存 Model 和 View 外 还 有 一 些 别 的 功能 ， 如 果 不 知道 这 些 功能 ， 很 多 代码 就 无 法 理解 。 先 看 一 下 它 里 面 所 包含 的 属性 ， 定 义 


如 下 : 


//org.springframework.web.method.support .ModelAndViewContainer 
private Object view; 


private final ModelMap defaultModel = new BindingAwareModelMap (); 
Private ModelMap redirectModel; 

Private final SessionStatus sessionStatus = new SimpleSessionstatus(); 
private boolean ignoreDefaultModelOnRedirect = false; 

Private boolean redirectModelScenario = false; 

Private boolean requestHandled = false; 


“ view: 视图 ，Object 类 型 的 ， 可 以 是 实际 视图 也 可 以 是 String 类 型 的 逻辑 视图 。 
defaultModel: 默认 使 用 的 Model。 
' redirectModel: redirect 类 型 的 Model。 


用 于 设置 SessionAttribute 使 用 完 的 标志 。 


* sessionStatus: 
* ignoreDefaultModelOnRedirect: 
处 理 器 返回 redirect 视 图 的 标志 。 


* redirectModelScenario: 


* requestHandled: 请 求 是 否 已 经 处 理 完成 的 标志 。 


如 果 为 true 则 在 处 理 器 返回 redirect 视 图 时 一 定 不 使 用 defaultModel。 


先 看 一 下 defaultModel 和 redirectModel， 这 两 个 都 是 Model， 前 者 是 默认 使 用 的 Model， 后 者 


于 传递 redirect 时 


入 defaultModel， 它 是 BindingAwareModelMap 类 型 ， 既 继承 了 ModelMap 又 实现 了 Model 接 
象 。 处 理 器 中 RedirectAttributes 类 型 的 参数 ArgumentResolver 会 传 入 redirectModel， 
个 Model 里 的 一 个 ， 代 码 如 下 : 


//org.springframework.web.method.support .ModelAndViewContainer 
public ModelMap getModel() { 
if (useDefaultModel()) { 
return this.defaultModel; 
} else { 
return (this.redirectModel != null) ? this.redirectModel : new ModelMap (); 
} 
E 
Private boolean useDefaultModel() { 
return (!this.redirectModelScenario || 


} 


判断 逻辑 在 useDefaultModel 中 ， 如 果 redirectModelScenario 为 false， 也 就 是 返 | 


如 下 : 


返回 


， 所 以 在 处 理 器 中 使 


回 的 不 是 redirect 视 | 


defaultModel 的 情况 : @ 处 理 器 返回 的 不 是 redirect 视 图 ; 


并 且 redirectMode 


返回 


redirectModel 的 情况 : @@ 处 理 器 返回 redirect 视 图 ， 不 为 null; 


ignoreDefaultModelOnRedirect 可 以 在 RequestMappingHandlerAdapter 中 设置 。 判 断 处 
置 的 ，ReturnValueHandler 如 果 判 断 到 是 redirect 视 图 
defaultModel， 处 理 后 才 可 能 是 redirectModel。 


现在 再 返回 去 看 RequestMappingHandlerAdapter 中 的 getModelAndView 方 法 getModel 后 判断 Mode| 是 


下 ， 在 处 理 器 中 设置 到 Model 中 的 参数 就 不 会 被 使 有 


时 器 返回 


@ 处 理 器 返回 的 是 redirect 视 图 


(this.redirectModel == null && !this.ignoreDefaultModelOnRedirect)); 


的 时 候 一 定 返 回 defaultModel, 
ignoreDefaultModelOnRedirect 的 情况 进一步 ， 如 果 redirectModel 不 为 空 和 ignoreDefaultModelOnRedirect 设 置 为 true 这 两 个 条 件 中 有 一 个 成 立 则 返 区 


7 并 


多 参数。 我们 在 处 理 器 中 使 用 了 Model 或 者 ModelMap 时 ArgumentResolver 会 传 
Model 或 者 ModelMap 其 实 使 
它 实际 上 是 RedirectAttributesModelMap 类 型 。ModelAndViewContainer 的 getMode| 方 法 会 根据 


的 是 同一 个 对 象 ，Map 参 数 传 入 的 也 是 这 个 对 
居 条 件 返 回 这 两 


如 果 返 加 


redirect 视 图 的 情况 下 需要 根据 redirectModel 和 
否则 返回 defaultModel。 


总 结 


redirectModel, 


@@ 处 理 器 返回 的 是 redirect 视 图 但 是 redirectMode| 为 null， 而 且 ignoreDefaultModelOnRedirect 也 是 false。 


ignoreDefaultModelOnRedirect 为 true。 


因 


defaultModel 里 的 参数 本 来 也 没什么 用 。 同 样 ， 如 果 返 回 defaultModel, 


了 (设置 SessionAttribute 除 外 ) 。 这 样 也 没有 什么 危害 ， 


不 是 RedirectAttributes 类 型 就 清楚 是 怎么 回 
为 只 有 redirect 的 情况 才 会 返 | 
设置 到 RedirectAttributes 中 的 参数 也 将 丢弃 ， 也 就 是 说 在 返回 的 View 不 是 redirect 类 型 时 ， 即 使 处 理 器 使 


的 是 不 是 redirect 视 图 的 标志 设置 在 redirectModelScenario 中 ， 它 是 在 ReturnValueHandler 中 设 
就 会 将 redirectModelScenario 设 置 为 true。 也 就 是 说 在 ReturnValueHandler 处 理 前 ModelAndViewContainer 的 getModel 返 回 


的 一 定 是 


反 回 redirectModel 的 情况 
泻 染 页 面 的 ， 所 以 
RedirectAttributes 


事 了 。 在 getModel 返 
回 redirectModel， 而 这 种 情况 是 不 需 


参数 设置 了 值 也 不 会 传递 到 下 一 个 请 求 。 


另外 ， 通 过 @sessionAttribute 传 递 的 参数 是 在 ModelFactory 中 的 updateMode| 方 法 中 设置 的 ， 那 里 使 用 了 mavContainer.getDefaultMode| 方 法 ， 这 样 就 确保 无 论 在 什么 情况 下 都 是 使 用 
defaultModel， 也 就 是 只 有 将 参数 设置 到 Model 或 者 ModelMap 里 才能 使 用 SessionAttribute 缓 存 ， 设 置 到 RedirectAttributes 里 的 参数 不 可 以 。 


ModelAndViewContainer 还 提供 了 添加 、 合 并 和 删除 属性 的 方法 ， 它 们 都 是 直接 调用 Model 操 作 的 ， 代 码 如 下 : 


//org.springframework.web.method.support .ModelAndViewContainer 

public ModelAndViewContainer addAttribute (String name, Object value) { 
getModel () .addAttribute (name, value); 
return this; 


} 

public ModelAndViewContainer addAttribute (Object value) { 
getModel () .adgAttribute (value); 
return this; 


} 

public ModelAndViewContainer addAllAttributes (Map<String, ?> attributes) { 
getModel () .addAllAttributes (attributes); 
return this; 


public ModelAndViewContainer mergeAttributes (Map<String, ?> attributes) { 
getModel () .mergeAttributes (attributes); 
return this; 
} 
public ModelAndViewContainer removeAttributes (Map<String, ?> attributes) { 
if (attributes != null) { 
for (String key : attributes.keySet()) { 
getMode]l () .remove (key); 
} 


return this; 


添加 、 删 除 属性 都 没什么 需要 说 的 ， 合 并 属性 的 逻辑 是 如 果 原 来 的 Model 中 不 包含 传 入 的 属性 则 添加 进去 ， 如 果 原 来 Model 中 已 经 有 了 就 不 操作 了 ， 具 体 代 码 在 ModelMap 中 ， 如 下 : 


// org.springframework.ui.ModelMap 
public ModelMap mergeAttributes (Map<String, ?> attributes) { 
if (attributes != null) { 
for (Map.Entry<String, ?> entry : attributes.entrySet()) { 
String key = entry.getKey () 7 
if (!containsKey (key)) { 
put (key, entry.getValue()); 
} 
E 
} 


return this; 


把 这 些 弄 明白 ModelAndViewContainer 基 本 就 明白 了 ， 剩 下 的 只 是 两 个 非常 简单 的 功能 。sessionStatus 属 性 就 是 在 处 理 器 中 通知 SessionAttribute 已 经 使 用 完 时 所 用 到 的 SessionStatus 类 型 的 参数 ， 
于 标示 SessionAttribute 是 否 已 经 使 用 完 ， 如 果 使 用 完了 则 在 ModelFactory 的 updateModeI| 方 法 中 将 SessionAttribute 的 相应 参数 清除 ， 否 则 将 当前 Model 的 相应 参数 设置 进去 。 


QI 


回 


requestHandled 用 于 标示 请 求 是 否 已 经 全 部 处 理 完 ， 如 果 是 就 不 再 往 下 处 理 ， 直 接 返回 。 这 里 的 全 部 处 理 完 主要 指 已 经 返回 response， 比 如 ， 在 处 理 器 返 
HttpEntity 类 型 等 情况 都 会 将 requestHandled 设 置 为 true。 


值 有 @ ResponseBody 注 释 或 者 返回 值 为 


13.4 _ SessionAttributesHandler 和 SessionAttributeStore 


SessionAttributesHandler 用 来 处 理 @SessionAttributes 注 释 的 参数 ， 不 过 它 只 是 做 一 些 宏观 的 事情 ， 比 如 ， 哪 个 Handler 都 可 以 缓存 哪些 参数 、 某 个 参数 在 当前 的 SessionAttributes 中 是 否 存 在 、 如 
何 同时 操作 多 个 参数 等 ， 而 具体 的 存储 工作 是 交 给 SessionAttributeStore 去 做 的 ， 不 过 SessionAttributeStore 并 不 是 保存 数据 的 容器 ， 而 是 用 于 保存 数据 的 工具 ， 具 体 保存 数据 的 容器 默认 使 用 的 是 
Session， 当 然 也 可 以 使 用 别 的 容器 ， 重 写 SessionAttributeStore 然 后 设置 到 RequestMappingHandlerAdapter， 在 SessionAttributeStore 中 保存 到 别 的 容器 就 可 以 了 ， 如 果 集 群 就 可 以 考虑 一 下 。 


SessionAttributesHandler 里 面 有 四 个 属性 : attributeNames、attributeTypes、knownAttribute-Names 和 sessionAttributeStore。sessionAttributeStore 是 SessionAttributeStore 类 型 的 ， 
具体 执行 Attribute 的 存储 工作 ， 前 三 个 属性 都 是 Set 类 型 ，attributeNames 存 储 @SessionAttributes 注 释 里 value 对 应 的 值 ， 也 就 是 参数 名 ，attributeTypes 存 储 @SessionAttributes 注 释 里 types 对 应 | 
值 ， 也 就 是 参数 类 型 ，knownAttributeNames 用 于 存储 所 有 已 知 可 以 被 当前 处 理 器 处 理 的 属性 名 ， 它 来 自 两 个 地 方 ， 首 先 在 构造 方法 里 会 将 所 有 attributeNames 的 值 设 置 到 knownAttributeNames 中 ， 
其 次 当 调用 isHandlerSessionAttribute 方 法 检查 ， 而 且 是 当前 Handler 所 管理 的 SessionAttributes 的 时 候 也 会 添加 到 knownAttributeNames， 而 保存 属性 的 storeAttributes 方 法 会 在 每 个 属性 保存 前 调 
sHandlerSessionAttribute 方 法 判断 是 否 支 持 要 保存 的 属性 ， 所 以 所 有 保存 过 的 属性 的 名 称 都 会 被 保存 在 knownAttributeNames 里 面 。knownAttributeNames 作 用 主要 是 保存 了 除了 使 用 value 配 置 的 名 
称 外 还 将 通过 types 配 置 的 已 经 保存 过 的 属性 名 保存 起 来 ， 这 样 在 清空 的 时 候 只 需要 遍历 knownAttributeNames 就 可 以 了 。 


i 


// org.springframework.web.method.annotation.SessionAttributesHandler 
public SessionAttributesHandler (Class<?> handlerType, SessionAttributeStore sessionAttributeStore) { 
Assert .notNull (sessionAttributeStore, "SessionAttributeStore may not be null."); 
this.sessionAttributeStore = sessionAttributestore; 
SessionAttributes annotation = AnnotationUtils.findAnnotation (handlerType, SessionAttributes.class); 
if (annotation != null) { 
this.attributeNames.addAll (Arrays.asList (annotation.value ())); 
this.attributeTypes.addAll (Arrays.<Class<?>>asList (annotation.types () ) ) 7 
} 
for (String attributeName : this.attributeNames) { 
this.knownAttributeNames .add (attributeName); 
} 


} 
public boolean isHandlerSessionAttribute (String attributeName, Class<?> attributeType) { 
Assert .notNull (attributeName, "Attribute name must not be null"); 
if (this.attributeNames.contains (attributeName) || this.attributeTypes.contains (attributeType)) { 
this.knownAttributeNames.add (attributeName); 
return true; 
} else { 
return false; 


} 


public void storeAttributes (WebRequest request, Map<String, ?> attributes) { 


for (String name : attributes.keySet()) { 
Object value = attributes.get (name); 
Class<?> attrType = (value != null) ? value.getClass() : null; 


if (isHandlerSessionAttribute (name, attrType)) { 
this.sessionAttributeStore. storeAttribute (request, name, value); 


} 


SessionAttributesHandler 中 除了 保存 属性 storeAttributes 的 方法 外 还 有 取 回 属性 值 的 retrieveAttributes 方 法 和 清空 属性 的 cleanupAttributes 方 法 ， 它 们 都 是 根据 knownAttributeNames 来 操作 的 。 
另外 还 有 按 属性 名 取 回 属性 的 retrieveAttribute 方 法 ， 代 码 如 下 : 


// org.springframework.web.method.annotation.SessionAttributesHandler 
public Map<String, Object> retrieveAttributes (WebRequest request) { 
Map<String, Object> attributes = new HashMap<string, Object>(); 
for (String name : this.knownAttributeNames) { 
Object value = this.sessionAttributeStore.retrieveAttribute (request, name); 
if (value != null) { 
attributes.put (name, value); 
} 
} 


return attributes; 


i 
public void cleanupAttributes (WebRequest request) { 
for (String attributeName : this.knownAttributeNames) { 
this.sessionAttributeStore.cleanupAttribute (request, attributeName); 
i 


} 
Object retrieveAttribute (WebRequest request, String attributeName) { 

return this.sessionAttributeStore.retrieveAttribute (request, attributeName) 7 
} 


需要 注意 的 是 ， 在 取出 全 部 属性 和 清除 属性 时 都 遍历 了 knownAttributeNames， 前 面 说 过 它 里 面 保 存 着 当前 Handler 注 释 里 所 有 使 用 过 的 属性 名 ， 所 以 这 两 个 方法 的 操作 只 是 对 当前 处 理 器 类 的 


@SessionAttributes 注 释 里 配置 的 属性 起 作用 ， 而 按 名 称 取 属 性 的 方法 可 以 在 整个 SessionAttributes 中 查找 ,没有 knownAttributeNames 的 限制 。 另 外 需要 注意 的 是 ， 如 果 在 不 同 的 Handler 中 
SessionAttributes 保 存 的 属性 使 用 了 相同 的 和 名称， 它们 会 相互 影响 。 


具体 对 每 个 参数 保存 、 取 回 和 删除 的 工作 是 由 SessionAttributeStore 完 成 的 。 这 是 一 个 接口 ， 里 | 
存 到 Session 中 ， 代 码 如 下 : 


对 


的 三 个 方法 分 别 对 应 上 述 三 个 功能 ， 它 的 默认 实现 类 是 DefaultSessionAttributeStore， 它 将 参数 保 


package org.springframework.web.bind.support; 
import org.springframework.util.Assert; 
import org.springframework.web.context .request .WebRequest; 
public class DefaultSessionAttributeStore implements SessionAttributeStore { 
private String attributeNamePrefix = ""; 
QOverride 
public void storeAttribute (WebRequest request, String attributeName, Object attributeValue) { 
Assert .notNull (request, "WebRequest must not be nul1") 7 
Assert .notNull (attributeName, "Attribute name must not be nul1") 7 
Assert.notNull (attributeValue, "Attribute value must not be null"™"); 
String storeAttributeName = getAttributeNameInSession (request, attributeName); 
request .setAttribute (storeAttributeName, attributeValue, WebRequest.SCOPE SESSION); 
} 
QOverride 
public Object retrieveAttribute (WebRequest request, String attributeName) { 
Assert .notNull (request, "WebRequest must not be null"™"); 
Assert .notNull (attributeName, "Attribute name must not be nul1") 7 
String storeAttributeName = getAttributeNameInSession (request, attributeName); 
return request.getAttribute (storeAttributeName, WebRequest.SCOPE SESSION); 
} 
QOverride 
public void cleanupAttribute (WebRequest request, String attributeName) { 
Assert .notNull (request, "WebRequest must not be null"™"); 
Assert .notNull (attributeName, "Attribute name must not be null"); 
String storeAttributeName = getAttributeNameInSession (request, attributeName); 
request .removeAttribute (storeAttributeName, WebRequest.SCOPE SESSION); 
} 
protected String getAttributeNameInSession (WebRequest request, String attributeName) { 
return this.attributeNamePrefix + attributeName; 
E 


需要 注意 的 是 ， 这 里 对 Session 的 操作 使 用 的 是 request 的 setAttribute、getAttribute 以 及 removeAttribute， 虽 然 是 request 调 用 的 ， 但 并 不 是 设置 到 了 request 上 面 ， 通 过 最 后 一 个 参数 指定 了 设置 范 


围 。 前 面 介 绍 过 ， 在 这 里 使 用 的 request 实 际 是 ServletWebRequest， 这 三 个 方法 在 : 
对 ServletRequestAttributes 介 绍 过 了 ， 下 面 再 看 一 下 它 的 setAttribute 的 代码 : 


父 类 servletRequestAttributes 里 定义 ， 它 可 以 通过 最 后 一 个 参数 指定 操作 的 范 | 


是 


， 在 分 析 FrameworkServlet 时 已 经 


org.springframework.web.context .request. ServletRequestAttributes 

public void setAttribute (String name, Object value, int scope) { 
if (scope 一 SCOPE REQUEST) { 

if (!isRequestActive()) { 

throw new IllegalStateException( 
"Cannot set request attribute - request is not active anymore!"); 
} 
this.request.setAttribute (name, value); 

} else { 
HttpSession session = getSession (true); 
this.sessionAttributesToUpdate .remove (name); 
session.setAttribute (name, value); 


如 果 第 三 个 参数 传 入 的 是 SCOPE_REQUEST 则 会 存储 到 request， 否 则 存储 到 Session。sessionAttributesToUpdate 属 性 用 于 保存 从 Session 中 获取 过 的 值 ， 最 后 request 使 


完 后 再 同步 给 Session， 因 


为 session 中 的 值 可 能 已 经 使 用 别 的 方式 修改 过 ， 如 果 不 好 理解 可 以 忽略 这 里 的 sessionAttributesToUpdate 属 性 ， 它 对 这 里 的 逻辑 没有 影响 。 总 之 ， 使 用 SCOPE_SESSION 会 对 Session 进 行 操作 ， 而 不 是 对 


request 操 作 。 


下 面 总 结 一 下 ，SessionAttributesHandler 与 @SessionAttributes 注 释 相 对 应 ， 用 于 对 Session-Attributes 操 作 ， 其 中 包含 判断 某 个 参数 是 否 可 以 被 处 理 以 及 批量 对 多 个 参数 进行 处 理 等 功能 。 


中 使 用 的 。 


13.5 ModelFactory 


ModelFactory 是 用 来 维护 Model 的 ， 具 体 包含 两 个 功能 : @ 初 始 化 Model; @ 处 理 器 执行 后 将 Model 中 相应 的 参数 更 新 到 SessionAttributes 中 。 


13.5.1 初始 化 Model 


初始 化 Model 主 要 是 在 处 理 器 执行 前 将 相应 数据 设置 到 Model 中 ， 是 通过 调用 initMode| 方 法 完成 的 ， 代 码 如 下 : 


体 对 


单个 参数 的 操作 是 交 给 SessionAttributeStore 去 完成 的 ， 它 的 默认 实现 DefaultSessionAttributeStore 使 用 ServletWebRequest 将 参数 设置 到 了 Session 中 。Session-AttributesHandler 是 在 ModelFactory 


// org.springframework.web.method.annotation.ModelFactory 
public void initModel] (NativeWebRequest request, ModelAndViewContainer mavContainer, HandlerMethod handlerMethod) throws Exception { 
// 从 SessionAttributes 中 取出 保存 的 参数 ， 并 合并 到 mavContainer 中 
Map<String, ?> sessionAttributes = this.sessionAttributesHandler.retrieveAttributes (request); 
mavContainer .mergeAttributes (sessionAttributes); 
// 执行 注释 了 @ModelAttribute 的 方法 并 将 结果 设置 到 Model 
invokeModelAttributeMethods (request, mavContainer); 
// 人 遍历 既 注 释 了 QModelAttribute 又 在 QSessionAttributes 注 释 中 的 参数 
for (String name : findSessionAttributeArguments (handlerMethod)) { 
if (!ImavContainer.containsAttribute(name)) { 
Object value = this.sessionAttributesHandler.retrieveAttribute (request, name); 


if (value == null) { 
throw new HttpSessionRequiredException ("Expected session attribute '" + name + "'"); 


} 


mavContainer.addAttribute (name, value); 


这 里 一 共 分 了 三 步 : @@ 从 SessionAttributes 中 取出 保存 的 参数 ， 并 合并 到 mavContainer 中 ; @ 执 行 注释 了 @ModelAttribute 的 方法 并 将 结果 设置 到 Model; @ 判 断 既 注释 了 @ModelAttribute 又 在 
@SessionAttributes 注 释 中 (参数 名 或 者 参数 类 型 在 注释 中 设置 着 ) 的 参数 是 否 已 经 设置 到 了 mavContainer 中 ， 如 果 没 有 则 使 用 SessionAttributesHandler 从 SessionAttributes 中 获取 并 设置 到 


mavContainer 中 。 


第 一 步 是 直接 在 initModel 中 完成 的 ， 代 码 也 非常 简单 ， 这 里 就 不 解释 了 。 


第 二 步 是 调用 invokeModelAttributeMethods 方 法 完成 的 ， 代 码 如 下 : 


// org.springframework.web.method.annotation.ModelFactory 
private void invokeModelAttributeMethods (NativeWebRequest request, ModelAndViewContainer mavContainer) 
throws Exception { 
while (!this.modelMethods.isEmpty()) { 
// 获取 注释 了 QModelAttribute 的 方法 
InvocableHandlerMethod attrMethod = getNextModelMethod (mavContainer) .getHandlerMethod () 7 
// 获取 注释 @ModelAttribute 中 设置 的 value 作 为 参数 名 
String modelName = attrMethod.getMethodannotation (ModelAttribute.class) .value (); 
// 如 果 参 数 名 已 经 在 mavContainer 中 则 跳 过 
if (mavContainer.containsAttribute (modelName)) { 
continue; 
} 
// 执行 GModelAttribute 注 释 的 方法 
Object returnValue = attrMethod.invokeForRequest (request, mavContainer); 
if (!attrMethod.isVoid())t{ 
// 使 用 getNameForReturnValue 获 取 参 数 名 
String returnValueName = getNameForReturnValue (returnValue, attrMethod.getReturnType () ) 7 
if (!mavContainer.containsAttribute (returnValueName)) { 
mavContainer.addAttribute (returnValueName, returnValue); 


} 


这 里 遍历 每 个 注释 了 @ModelAttribute 的 方法 ， 然 后 从 注释 中 获取 参数 名 ， 如 果 获 取 到 了 (注释 中 设置 了 value) ， 而 且 在 mavContainer 中 已 经 存在 此 参数 了 则 跳 过 此 方法 ， 否 则 执行 方法 (这 时 的 方 
法 封装 成 了 InvocableHandlerMethod 类 型 ， 可 以 直接 执行 ， 后 面 会 详细 讲解 ) ， 执 行 完 之 后 判断 返回 值 是 不 是 Void 类 型 ， 如 果 是 则 说 明 这 个 方法 是 自己 将 参数 设置 到 Model 中 的 ， 这 里 就 不 处 理 了 ， 否 则 
使 用 getNameForReturnValue 方 法 获取 到 参数 名 ， 并 判断 是 否 已 存在 mavContainer 中 ， 如 果 不 存 在 则 设置 进去 。 


这 里 的 重点 是 获取 参数 名 的 规则 ， 获 取 参 数 名 的 getNameForReturnValue 方 法 代码 如 下 : 


// org.springframework.web.method.annotation.ModelFactory 
public static String getNameForReturnValue (Object returnValue, MethodParameter returnType) { 
ModelAttribute annotation = returnType.getMethodAnnotation (ModelAttribute.class); 
if (annotation != null && StringUtils.hasText (annotation.value())) { 
return annotation.value(); 
} 
else { 
Method method = returnType.getMethod () ; 
Class<?> resolvedType = GenericTypeResolver.resolveReturnType (method, returnType.getContainingClass()); 
return Conventions.getVariableNameForReturnType (method, resolvedType, returnValue); 


， 否 则 使 用 Conventions 的 静态 方法 get- 


回 


这 里 首先 获取 了 返回 值 的 @ModelAttribute 注 释 ， 也 就 是 方法 的 @ModelAttribute 注 释 ， 如 果 设 置 了 value 则 直接 将 其 作为 参数 名 返 
VariableNameForReturnTyp 根 据 方法 、 返 回 值 类 型 和 返回 值 获取 参数 名 ， 其 代码 如 下 : 


// org.springframework.core.Conventions 
public static String getVariableNameForReturnType (Method method, Class<?> resolvedType, Object value) { 
Assert .notNull (method, "Method must not be nul1") 7 
if (Object.class.equals (resolvedType)) { 
if (value == null) { 
throw new IllegalArgumentException ("Cannot generate variable name for an Object return type with null value"); 
} 
return getVariableName (value); 
} 
Class<?> valueClass; 
boolean pluralize = false; 
if (resolvedType.isArray()) { 
valueClass = resolvedType.getComponentType (); 
pluralize = true; 
}else if (Collection.class.isAssignableFrom(resolvedType)) { 
valueClass = GenericCollectionTypeResolver.getCollectionReturnType (method); 
if (valueClass == null) { 
if (!(value instanceof Collection)) { 
throw new IllegalArgumentException ("Cannot generate variable name for non-typed Collection return type and a non-Collection value"); 
} 
Collection<?> collection = (Collection<?>) value; 
if (collection.isEmpty()) { 


throw new IllegalArgumentException( 
"Cannot generate variable name for non-typed Collection return type and an empty Collection value"); 


Object valueToCheck = peekAhead (collection); 
valueClass = getClassForValue (valueToCheck); 
} 
pluralize = true; 
jelse { 
valueClass = resolvedType; 


} 
String name = ClassUtils.getShortNameAsProperty (valueClass); 


return (pluralize ? pluralize (name) : name); 


代码 比较 长 ， 它 的 核心 逻辑 就 是 获取 返回 值 类 型 的 “ShortName”。 “ShortName” 是 使 用 ClassUtils 的 getShortrNameAsProperty 方 法 获取 的 ， 具 体 逻 辑 是 先 获取 到 去 掉包 名 之 后 的 类 名 ， 然 后 再 判 
断 类 名 是 不 是 大 于 一 个 字符 ， 而 且 前 两 个 字符 都 是 大 写 ， 如 果 是 则 直接 返回 ， 否 则 将 第 一 个 字符 变 成 小 写 返回 。 不 过 这 里 的 方法 返回 值 类 型 如 果 是 Object 则 会 使 用 返回 值 的 实际 类 型 ， 如 果 返 回 值 为 数组 或 
者 Collection 类 型 时 会 使 用 内 部 实际 包装 的 类 型 ， 并 在 最 后 加 “List”。 下 面 看 几 个 例子 。 


String > string 
ClassUtils > classUtils 
UFOModel >UFOModel 
List<Double> 一 一 > doubleList 
Set<Double> ”一 一 > doubleList 
Double [] “一 一 >dqoubleList 


这 一 步 的 难点 在 解析 参数 名 ， 如 果 理 解 了 解析 参数 名 的 规则 ， 这 一 步 也 就 理解 了 。 这 一 步 的 整个 流程 是 首先 会 判断 返回 值 是 不 是 Void 类 型 ， 如 果 是 则 不 处 理 了 ， 如 果 不 是 则 先 判断 注释 里 有 没 
value， 如 果 有 则 使 用 注释 的 value 做 参数 名 ， 如 果 没 有 则 根据 上 面 说 的 规则 来 解析 出 参数 名 ， 最 后 判断 得 到 的 参数 名 是 否 已 经 存在 mavContainer 中 ， 如 果 不 存在 则 将 其 和 返回 值 添加 到 mavContainer 中 。 


第 三 步 是 遍历 既 注释 了 @ModelAttribute 又 在 @SessionAttributes 注 释 中 的 参数 ， 判 断 是 否 已 经 存在 mavContainer 生 


了， 如 果 没 有 则 使 用 SessionAttributesHandler 从 整个 SessionAttributes 中 获取 
(第 一 步 获取 的 是 当前 处 理 器 保存 到 SessionAttributes 的 属性 ) ， 如 果 可 以 获取 到 则 设置 到 mavContainer 中 ， 如 果 获 取 不 到 则 抛 出 异常 。 这 里 获取 同时 有 @ModelAttribute 注 释 又 在 @sessionAttributes 
注释 中 的 参数 的 方法 是 findSessionAttribute-Arguments， 代 码 如 下 : 


// org.springframework.web.method.annotation.ModelFactory 
private List<String> findSessionAttributeArguments (HandlerMethod handlerMethod) { 
List<String> result = new ArrayList<string>(); 
for (MethodParameter parameter : handlerMethod.getMethodParameters()) { 
if (parameter.hasParameterAnnotation (ModelAttribute.class)) { 
String name = getNameForParameter (parameter); 
if (this.sessionAttributesHandler.isHandlerSessionAttribute (name, parameter.getParameterType())) { 
result .add (name); 
} 
} 
i 


return result; 


它 的 逻辑 是 遍历 方法 里 的 每 个 参数 ， 如 果 有 @MeodelAttribute 注 释 则 获取 到 它 对 应 的 参数 名 ， 然 后 
@ModelAttribute 注 释 的 参数 对 应 参数 名 的 方法 是 getNameForParameter， 代 码 如 下 : 


获取 到 的 参数 名 和 参数 的 类 型 检查 是 不 是 在 @ SessionAttributes 注 释 中 ， 如 果 在 则 符合 要 求 。 获 取 


// org.springframework.web.method.annotation.ModelFactory 
public static String getNameForParameter (MethodParameter parameter) { 


ModelAttribute annot = parameter.getParameterAnnotation (ModelAttribute.class); 
String attrName = (annot != null) ? annot.value() : null; 


return StringUtils.hasText (attrName) ? attrName : Conventions.getVariableNameForParameter (parameter); 


这 里 首先 从 注释 中 获取 ， 如 果 注 释 没有 则 使 用 Conventions 的 getVariableNameFor Parameter 方 法 获取 ， 代 码 如 下 : 


// org.springframework.core.Conventions 
public static String getVariableNameForParameter (MethodParameter parameter) { 
Assert .notNull (parameter, "MethodParameter must not be null"); 
Class<?> valueClass; 
boolean pluralize = false; 
if (parameter.getParameterType().isArray()) { 
valueClass = parameter.getParameterType () .getComponentType (); 
pluralize = true; 
}else if (Collection.class.isAssignableFrom(parameter.getParameterType())) { 


valueClass = GenericCollectionTypeResolver.getCollectionParameterType (parameter); 
if (valueClass == null) { 


throw new IllegalArgumentException( 
"Cannot generate variable name for non-typed Collection parameter type"); 


} 
pluralize = true; 
jelse { 
valueClass = parameter.getParameterType (); 
} 
String name = ClassUtils.getShortNameAsProperty (valueClass); 
return (pluralize ? pluralize (name) : name); 


这 里 跟 第 二 步 里 的 getVariableNameForReturnType 方 法 的 逻辑 是 一 样 的 ， 就 不 细 讲 了 。 


第 三 步 跟 第 一 步 的 区 别 是 第 一 步 是 将 当前 处 理 器 中 保存 的 所 有 SessionAttributes 属 性 合并 到 了 mavContainer， 而 第 三 步 可 以 使 用 
@ModelAttribute 的 参数 。 


他 处 理 器 中 保存 的 SessionAttributes 属 性 来 设置 注释 了 


这 三 步 就 讲 完 了 ， 最 后 再 总 结 一 下 ， 首 先 将 当前 处 理 器 中 保存 的 所 有 SessionAttributes 属 性 合并 到 mavContainer， 然 后 执行 注释 了 @ModelAttribute 的 方法 并 将 结果 合并 到 mavContainer， 最 后 检 


查 注释 了 @MeodelAttribute 而 且 在 @SessionAttributes 中 也 设置 了 的 参数 是 否 已 经 添加 到 了 mavContainer 中 ， 如 果 没有 则 从 整个 SessionAttributes 中 获取 出 来 并 设置 进去 ， 如 果 获 取 不 到 则 抛 出 异常 。 整 
个 过 程 的 重点 和 难点 是 获取 设置 到 Model 中 的 参数 名 的 规则 。 


从 这 里 可 以 看 出 Model 中 参数 的 优先 级 是 这 样 的 : @FlashMap 中 保存 的 参数 优先 级 最 高 ， 它 在 ModelFactory 前 面 执行 ; @OSessionAttributes 中 保存 的 参数 的 优先 级 第 二 ， 它 不 可 以 覆盖 FlashMap 中 


设置 的 参数 ; @ 通 过 注释 了 @MeodelAttribute 的 方法 设置 的 参数 优先 级 第 三 ; @ 注 释 了 @ModelAttribute 而 且 从 别 的 处 理 器 的 sessionAttributes 中 获取 的 参数 优先 级 最 低 。 而 且 从 前 面 创建 ModelFactory 
的 过 程 可 以 看 出 ， 注 释 了 @ModelAttribute 的 方法 是 全 局 的 优先 ， 处 理 器 自己 定义 的 次 之 。 


13.5.2 ”更 新 Model 


更 新 Model 是 通过 updateMode| 方 法 完成 的 ， 代 码 如 下 : 


// org.springframework.web.method.annotation.ModelFactory 
public void updateModel (NativeWebRequest request, ModelAndViewContainer mavContainer) throws Exception { 
ModelMap defaultModel = mavContainer.getDefaultModel (); 
if (mavContainer.getSessionStatus () .isComplete()){ 
this.sessionAttributesHandler.cleanupAttributes (request); 
}else { 


this.sessionAttributesHandler.storeAttributes (request, defaultModel); 

} 

if (!mavContainer.isRequestHandled() && mavContainer.getModel() 一 defaultModel) { 
updateBindingResult (request, defaultModel); 


这 里 做 了 两 件 事 : @ 对 SessionAttributes 进 行 设 置 ， 设 置 规则 是 如 果 处 理 器 里 调 有 


了 SessionStatus#setComplete 则 将 SessionAttributes 清 空 ， 否 则 将 mavContainer 的 defaultModel 中 相应 的 参数 设 
置 到 SessionAttributes 中 ; @ 判 断 请 求 是 否 已 经 处 理 完 或 者 是 redirect 类 型 的 返回 值 ， 其 实 也 就 是 判断 需要 不 需要 演 染 页 面 ， 如 果 需 要 演 染 则 给 Model 中 相应 参数 设置 BindingResult。 


我 们 知道 在 处 理 器 中 绑 定 参数 时 如 果 参 数 注释 了 @Valid 或 者 @Validated， 则 会 将 校 验 结果 设置 到 跟 其 相 邻 的 下 一 个 Error 或 者 BindingResult 类 型 的 参数 中 。 如 果 参 数 没 有 @Valid 和 @Validated 注 释 


但 在 Model 中 ， 而 且 符 合 条件 (具体 条 件 下 面具 体 讲解 ) ， 这 时 为 了 泻 染 方便 ModelFactory 会 给 Model 设 置 一 个 跟 参 数 相对 应 的 BindingResult， 不 过 这 里 设置 的 BindingResult 里 面 并 没有 校 验 的 错误 
值 ， 因 为 这 里 并 没有 调用 Binder 的 validate 方 法 来 校 验 参数 。 具 体 设置 的 方法 是 updateBindingResult， 代 码 如 下 : 


// org.springframework.web.method.annotation.ModelFactory 
private void updateBindingResult (NativeWebRequest request, ModelMap model) throws Exception { 
List<String> keyNames = new ArrayList<String> (model .keySet ()); 
for (String name : keyNames) { 
Object value = model .get (name); 
if (isBindingCandidate (name, value)) { 
String bindingResultKey = BindingResult .MODEL KEY PREFIX + name; 
if (!model.containsAttribute (bindingResultKey)) { 
WebDataBinder dataBinder = dataBinderFactory.createBinder (request, value, name); 
model .put (bindingResultKey, dataBinder.getBindingResult ()); 
! 


这 里 首先 取出 Model 中 保存 的 所 有 参数 进行 遍历 ， 然 后 通过 isBindingCandidate 方 法 判断 是 否 需要 添加 BindingResult， 如 果 需 要 则 使 用 WebDataBinder 获 取 BindingResult 并 添加 到 Model， 在 添加 
前 先 检查 Model 中 是 否 已 经 存在 ， 如 果 已 经 存在 就 不 添加 了 。 判 断 是 否 需要 添加 BindingResult 的 isBindingCandidate 方 法 代码 如 下 : 


// org.springframework.web.method.annotation.ModelFactory 
Private boolean isBindingCandidate (String attributeName, Object value) { 
if (attributeName.startsWith (BindingResult .MODEL KEY PREFIX)) { 
return false; 
} 
Class<?> attrType = (value != null) ? value.getClass() : null; 
if (this.sessionAttributesHandler.isHandlerSessionAttribute (attributeName, attrType)) { 
return true; 
} 
return(value != null && !value.getClass().isArray() && ! (value instanceof Collection) && 
! (value instanceof Map) && !BeanUtils.isSimpleValueType (value.getClass())); 


这 里 判断 的 逻辑 是 先 判断 他 本 身 是 不 是 其 他 参数 绑 定 结果 的 BindingResult (通过 固定 的 前 缀 判断 ) ， 如 果 是 则 不 需要 再 对 它 添加 BindingResult 了 返回 false， 然 后 判断 是 不 是 SessionAttributes 管 理 的 
属性 ， 如 果 是 则 返回 true， 最 后 检查 如 果 不 是 空 值 、 数 组 、Collection、Map 和 简单 类 型 (如 boolean、byte、char、short、int、long、float、double、Boolean、Byte、Character、Short、 
Integer、Long、Float、Double、Enum、Number、Date 等 ) 则 返回 true 添 加 BindingResult。 


也 就 是 说 如 果 不 是 BindingResult、 空 值 、 数 组 、Collection、Map 和 简单 类 型 都 会 返回 true， 如 果 是 这 些 类 型 但 是 在 SessionAttributes 中 设置 了 ， (除了 BindingResult 类 型 ) 也 会 返回 true， 其 他 情 
况 就 返回 false。 


updateModel| 一 共 做 了 两 件 事 ， 第 一 件 事 是 维护 SessionAttributes 的 数据 ， 第 二 件 事 是 给 Model 中 需要 的 参数 设置 BindingResult， 以 备 视图 使 用 。 


多 知道 点 


Redirect 转 发 后 的 参数 怎么 校 验 


在 处 理 器 中 如 果 想 对 一 个 参数 进行 校 验 只 需要 在 前 面 加 上 (@Valid 或 者 @Validated 注 释 就 可 以 了 ， 但 是 Redirect 转 发 后 校 验 结果 就 丢失 了 ， 因 为 它 默 认 是 保存 在 ModelAndViewContainet 的 defaultModel 中 的 ， 
而 FlashMap 只 会 传递 redirectModel 里 保存 的 参数 ， 所 以 校 验 结果 就 会 丢失 。 


如 果 想 传递 校 验 参数 可 以 有 两 种 方法 ， 一 种 是 通过 SessionAttributes 传 递 ， 这 时 只 需要 在 处 理 器 类 上 注释 @SessionAttributes (types={BindingResult.class}) 即 可 ， 这 样 BindingResult 类 型 的 参数 就 会 被 保存 
到 SessionAtttibutes 中 ， 在 teditect 处 理 器 方法 中 设置 SessionStatus#setComplete 就 可 以 了 。 如 果 使 用 这 种 方法 一 定 要 及 时 清空 SessionAttributes (给 Session-Status 设 置 Complete) ,否则 可 能 会 造成 混乱 。 


男 一 种 方法 的 思路 是 重新 校 验 一 遍 ， 要 使 用 这 种 方法 首先 需要 明白 Spring MVC 是 在 哪里 校 验 参数 的 。Spring MVC 校 验 参 数 是 在 ModelAttributeMethodProcessor 参 数 解 析 的 时 候 判 断 有 没有 @Valid 或 者 
@Validated 注 释 ， 如 果 有 就 会 校 验 ，ModelAttribute-MethodProcessor 解 析 器 用 于 解析 注释 了 @ModelAttribute 的 参数 和 没 注释 的 非 通用 类 型 (如 自 定义 类 型 ) 的 参数 ， 所 以 可 以 在 redirect 后 的 处 理 器 中 将 需要 校 
验 的 参数 写 到 处 理 器 的 参数 中 并 注释 @Valid 或 者 @Validated， 这 种 方法 更 加 清晰 ， 而 且 不 容易 出 问题 ， 所 以 建议 大 家 尽量 使 用 这 种 方式 。 下 面 来 看 个 例子 。 


@RequestMapping (value={"/signup"},method= {RequestMethod.POST}) 
public String signup( Q@Validated User user, BindingResult br, 
RedirectAttributesra) throws Exception { 
ra.addFlashAttribute ("user", user); 
return "redirect:show"; 


} 

@RequestMapping (value={"/show"},method= {RequestMethod.GET}) 

public String show(@Validated User user, BindingResult br) throws Exception { 
return "/user.jsp"; 


i 


当 用 户 发 出 Post 的 /signup 请 求 后 会 tedirect 到 /show 对 应 的 show 处 理 器 方法 ，show 方 法 添加 了 User 参 数 并 且 添 加 了 (@Validated 注 释 ， 所 以 ModelAttributeMethodProcessor 参 数 解析 器 在 解析 的 时 候 就 会 将 校 验 
结果 设置 到 Model 中 。 


13.6 ServletInvocableHandlerMethod 


ServletlnvocableHandlerMethod 的 继承 结构 如 


13-4 所 示 。 


[ 


可 以 看 出 ServletlnvocableHandlerMethod 其 实 也 是 一 种 HandlerMethod， 只 是 增加 了 方法 执行 的 功能 。 当 然 相应 地 也 增加 了 参数 解析 、 返 回 值 处 理 等 相关 功能 。 之 前 一 直 使 用 HandlerMethod， 但 
还 没有 对 它 的 结构 进行 过 分 析 ， 本 节 就 从 HandlerMethod 开 始 依次 对 这 三 个 组 件 进 行 分 析 。 


L HandlerMethod 


UL InvocableHandlerMethod 


LU ServletInvocableHandlerMethod 


图 13-4 ServletInvocableHandler-Method 继 承 结 构图 


13.6.1 HandlerMethod 


HandlerMethod 前 面 已 经 介绍 过 了 ， 用 于 封装 Handler 和 其 中 具体 处 理 请 求 的 Method， 分 别 对 应 其 中 的 bean 和 method 属 性 ， 除 了 这 两 个 还 有 三 个 属性 : beanFactory、bridgedMethod 和 
parameters。beanFactory 主 要 用 于 新 建 HandlerMethod 时 传 入 的 Handler (也 就 是 bean 属 性 ) 是 String 的 情况 ， 这 时 需要 使 用 beanFactory 根 据 传 入 的 String 作 为 beanName 获 取 到 对 应 的 bean， 并 设 
置 为 Handler; bridgedMethod 指 如 果 method 是 bridge method 则 设置 为 其 所 对 应 的 原 有 方法 ， 否 则 直接 设置 为 method; parameters 代 表 处 理 请 求 的 方法 的 参数 。 定 义 如 下 : 


// org.springframework.web.method.HandlerMethod 
private final Object bean; 

private final BeanFactory beanFactory; 

private final Method method; 

private final Method bridgedMethod; 

Private final MethodParameter[] parameters; 


这 里 所 有 的 属性 都 是 final 的 ， 所 以 创建 后 就 不 可 以 修改 了 ， 前 面 说 的 如 果 Handler 是 String 类 型 ， 将 其 变 为 容器 中 对 应 bean 的 过 程 在 专门 的 方法 createWithResolvedBean 中 来 操作 的 ， 这 里 面 是 通过 
使 用 从 容器 中 找到 的 bean 和 自己 原来 的 属性 新 建 一 个 HandlerMethod 来 完成 的 ， 代 码 如 下 : 


// org.springframework.web.method.HandlerMethod 
public HandlerMethod createWithResolvedBean() { 
Object handler = this.bean; 
if (this.bean instanceof String) { 
String beanName = (String) this.bean; 
handler = this.beanFactory.getBean (beanName); 
i 
return new HandlerMethod (this, handler); 

} 

Private HandlerMethod (HandlerMethod handlerMethod, Object handler) { 
Assert .notNull (handlerMethod, "HandlerMethod is required"); 
Assert .notNull (handler, “Handler object is required"); 
this.bean = handler; 
this.beanFactory = handlerMethod.beanFactory; 
this.method = handlerMethod.method; 
this.bridgedMethod = handlerMethod.bridgedMethod; 
this.parameters = handlerMethod.parameters; 


HandlerMethod 中 属性 的 含义 除了 bridgedMethod 外 都 比较 容易 理解 ， 只 是 保存 参数 的 属性 parameters 使 用 了 大 家 可 能 不 太 熟 悉 的 类 型 MethodParameter。 一 个 MethodParameter 类 型 的 对 象 表 
示 一 个 方法 的 参数 ， 对 MethodParameter 主 要 是 理解 其 参数 的 含义 ， 它 们 定义 如 下 : 


Package org.springframework.core; 

// 省 略 了 imports 

Public class MethodParameter { 
private final Method method; 
private final Constructor<?> constructor; 
private final int parameterIndex; 
Private int nestingLevel = 1; 
private volatile Class<?> containingClass; 
private volatile Class<?> parameterType; 
Private volatile Type genericParameterType; 
Private volatile Annotation[] parameterAnnotations; 


private Volatile ParameterNameDiscoverer parameterNameDiscoverer; 
private volatile String parameterName; 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/15447/OEBPS/Text/... 


下 面 分 别 来 解释 : 
“ method: 参数 所 在 的 方法 。 
“ constructor: 参数 的 构成 方法 。 
“ parameterIndex: 参数 的 序号 ， 也 就 是 第 几 个 参数 ， 从 0 开始 计数 。 
“nestingLevel: 谈 套 级 别 ， 如 果 是 复合 参数 会 用 到 ， 比 如 ， 有 一 个 Listparams 参 数 ， 则 params 的 谋 套 级 别 为 1，List 内 部 的 String 的 谍 套 级 别 为 2。 
“ typeIndexesPerLevel: 保存 每 层 识 套 参数 的 序数 。 
“containingClass: 容器 的 类 型 ， 也 就 是 参数 所 属 方法 所 在 的 类 。 
arameterType: 参数 的 类 型 。 
“ genericParameterType: Type 型 的 参数 类 型 ， 也 是 参数 的 类 型 ， 但 它 的 类 型 是 Type。 
arameterAnnotations: 参数 的 注释 。 


atametetNameDiscovetet: 参数 名 称 查找 器 。 


atameterName: 参数 名 称 。 


MethodParameter 里 最 重要 的 是 method 和 parameterlndex， 有 了 这 两 个 参数 后 参数 类 型 、 注 释 等 都 可 以 获取 到 。 不 过 在 正常 的 反射 技术 里 是 不 知道 参数 名 的 ， 所 以 这 里 专门 使 用 了 一 个 参数 名 查找 
的 组 件 parameterNameDiscoverer， 它 可 以 查找 出 我 们 定义 参数 时 参数 的 名 称 ， 这 就 给 ArgumentResolver 的 解析 提供 了 方便 。 


在 HandlerMethod 中 定义 了 两 个 内 部 类 来 封装 参数 ， 一 个 封装 方法 调用 的 参数 ， 一 个 封装 方法 返回 的 参数 ， 它 们 主要 使 用 method 和 parameterlndex 来 创建 MethodParameter， 封 装 返回 值 的 
ReturnValueMethodParameter 继 承 自封 装 调用 参数 的 HandlerMethodParameter， 它 们 使 用 的 method 都 是 bridgedMethod， 返 回 值 使 用 的 parameterlndex 是 -1， 代 码 如 下 : 


// org.springframework.web.method.HandlerMethod 
protected class HandlerMethodParameter extends MethodParameter { 
public HandlerMethodParameter (int index) { 
super (HandlerMethod.this.bridgedMethod, index); 
} 
QOverride 
public Class<?> getContainingClass() { 
return HandlerMethod.this.getBeanType(); 


QOverride 

public <T extends Annotation> T getMethodAnnotation (Class<T> annotationType) { 
return HandlerMethod.this.getMethodAnnotation (annotationType); 

i 


} 
Private class ReturnValueMethodParameter extends HandlerMethodParameter { 
private final Object returnValue; 
public ReturnValueMethodParameter (Object returnValue) { 
super (-1) 7 
this .returnValue = returnValue; 


QOverride 
public Class<?> getParameterType() { 

return (this.returnValue != null ? this.returnValue.getClass() : super.getParameterType()); 
} 


现在 大 家 就 明白 HandlerMethod 是 怎么 回 事 了 。 下 面 再 给 大 家 介绍 什么 是 bridge method ( 桥 方法 ) 。 


多 知道 点 


什么 是 bridge method 


Bridge method 是 Java 里 的 一 个 概念 ， 不 过 正常 情况 下 使 用 得 并 不 多 。 在 java 说 明 书 《The Java LanguageSpecification》 中 “Method Invocation Expressions” 一 节 介绍 了 bridge method。 举 例如 下 : 


abstract class C<T> { 
abstract T id(T x) 
} 
class D extends C<String> { 
public String id(String x) { return x; } 


} 
Ce= new D(); 
c.id(new Object ()); 


在 C 类 中 定义 了 泛 型 ， 子 类 D 中 给 泛 型 设置 了 String， 使 用 时 新 建 了 D 类 型 的 C， 调 用 时 由 于 C 中 泛 型 没有 指定 具体 的 类 型 ， 所 以 可 以 给 它 的 id 方法 传 入 任意 类 型 的 参数 ， 所 以 上 面 的 代码 中 传 入 Object 编译 
并 没有 问题 ， 但 实际 使 用 的 是 D 类 型 的 实例 ，D 给 泛 型 设置 了 String， 这 在 运行 时 就 出 错 了 。 


在 Java 唐 拟 机 中 其 实 会 给 D 创 建 两 个 id 方法 ， 除 了 我 们 定义 的 Sting 为 参数 的 这 方 法， 还 会 创建 一 个 Object 做 参数 的 方法 〈 这 一 点 也 可 以 通过 调用 D.class.getMethods0 看 到 ， 只 是 D 中 的 这 方法 需要 是 public 
的 ) ， 创 建 的 方法 如 下 : 


Object id(Object x) { return id((String) x); } 


这 个 Object 为 参数 的 方法 就 叫 桥 方法 (bridge method) ， 它 作为 一 个 桥 将 Object 为 参数 的 调用 转换 到 了 String 为 参数 的 方法 。 


在 HandlerMethod 中 的 bridgedMethod 指 的 是 被 桥 的 方法 (注意 是 bridged 而 不 是 bridge) ， 也 就 是 原来 的 方法 。 比 如 ，HandlerMethod 中 的 method 如 果 是 Object 类 型 的 id 方 法 ，bridgedMethod 就 是 String 类 型 的 id 
方法 ， 如 果 method 是 String 类 型 的 id 方 法 ，bridgedMethod 将 和 method 代 表 同 一 个 方法 ， 如 果 不 涉 及 泛 型 bridgedMethod 和 method 都 是 同一 个 方法 。 在 spring 中 获取 原 方法 bridgedMethod 是 通过 
BridgeMethodResolver.findBridgedMethod 来 完成 的 ， 大 概 思 路 是 按 相 同 的 方法 名 和 相同 的 参数 个 数 找 不 是 桥 的 方法 。 


13.6.2 InvocableHandlerMethod 


InvocableHandlerMethod 继 承 自 HandlerMethod， 在 父 类 基础 上 添加 了 调用 的 功能 ， 也 就 是 说 InvocableHandlerMethod 可 以 直接 调用 内 部 属性 method 对 应 的 方法 (严格 来 说 应 该 是 


bridgedMethod) 。 


InvocableHandlerMethod 里 增加 了 三 个 属性 : 


“dataBinderFactory: WebDataBinderFactory 类 型 ， 可 以 创建 WebDataBinder， 用 于 参数 解析 器 ArgumentResolver 中 。 
“ argumentResolvers: HandlerMethodArgumentResolverComposite 类 型 ， 用 于 解析 参数 。 


“ parameterNameDiscoverer: ParameterNameDiscoverer 类 型 ， 用 来 获取 参数 名 ， 用 于 MethodParameter 中 。 


InvocableHandlerMethod 中 Method 调 用 的 方法 是 invokeForRequest， 代 码 如 : 


//org.springframework.web.method.support.InvocableHandlerMethod 
public Object invokeForRequest (NativeWebRequest request, ModelAndViewContainer mavContainer, 
Objecthttp://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/15447/0EBPS/Text/... providedArgs) throws Exception { 
Object[] args = getMethodArgumentValues (request, mavContainer, providedArgs); 
if (logger.isTraceEnabled()) { 
StringBuilder sb = new StringBuilder ("Invoking ["); 
sb.append (getBeanType () .getSimpleName () ) .append (".") 7 
sb.append (getMethod () .getName () ) .append ("] method with arguments "); 
sb.append (Arrays.asList (args) ) 7 
logger.trace (sb.toString()) 7 
Object returnValue = doInvoke (args) 7 
if (logger.isTraceEnabled()) { 
logger.trace ("Method [" + getMethod () .getName () + "] returned [" + returnValue + " 


} 


return returnValue; 


这 个 方法 非常 简单 ， 除 了 日 志 打印 就 两 条 代码 了 ， 一 条 是 准备 方法 所 需要 的 参数 ， 使 用 的 是 getMethodArgumentValues 方 法 ， 另 一 条 用 于 具体 调用 Method， 具 体 使 用 的 方法 是 dolnvoke 方 法 。 


dolnvoke 方 法 是 实际 执行 请 求 处 理 的 方法 ， 我 们 写 的 代码 都 是 通过 它 来 执行 的 ， 所 以 这 个 方法 是 整个 HandlerMethod 系 列 的 处 理 器 中 最 核心 的 方法 ， 不 过 它 的 代码 非常 简单 ， 如 下 所 示 : 


//org.springframework.web.method.support.InvocableHandlerMethod 
protected Object doInvoke (Objecthttp://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/15447/0EBPS/Text/... args) throws Exception { 
ReflectionUtils.makeAccessible (getBridgedMethod ()); 
try { 
return getBridgedMethod () .invoke (getBean(), args); 
} catch (IllegalArgumentException ex) { 
assertTargetBean (getBridgedMethod(), getBean(), args); 
throw new IllegalStateException (getInvocationErrorMessage (ex.getMessage (), args), ex); 
} catch (InvocationTargetException ex) { 
// Unwrap for HandlerExceptionResolvers http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/15447/0EBPS/Text/... 
Throwable targetException = ex.getTargetException(); 9 
if (targetException instanceof RuntimeException) { 
throw (RuntimeException) targetException; 
} else if (targetException instanceof Error) { 
throw (Error) targetException; 
}else if (targetException instanceof Exception) { 
throw (Exception) targetException; 
}else { 
String msg = getInvocationErrorMessage ("Failed to invoke controller method", args); 
throw new IllegalStateException (msg, targetException); 


除了 异常 处 理 外 ， 真 正 执行 的 方法 就 是 直接 调用 bridgedMethod 的 invoke 方 法 ， 在 调用 前 先 使 用 ReflectionUtils.makeAccessible 强 制 将 它 变 为 可 调用 ， 也 就 是 说 即使 我 们 定义 的 处 理 器 方法 是 private 


的 也 可 以 被 调用 。 


再 返回 来 看 一 下 参数 绑 定 的 getMethodArgumentValues 方 法 ， 代 码 如 下 : 


//org.springframework.web.method.support.InvocableHandlerMethod 


private Object[] getMethodArgumentValues (NativeWebRequest request, ModelAndViewContainer mavContainer, Objecthttp://www.hzcourse.com/resource/readBook?path=/openresources/teack 


// 获取 方法 的 参数 ， 在 HandlerMethod 中 
MethodParameter[] parameters = getMethodParameters () 7 
// 用 于 保存 解析 出 参数 的 值 
Object[] args = new Object [parameters.length]; 
for (int i = 0; i < parameters.length; i++) { 
MethodParameter parameter = parameters[i]; 
// 给 parameter 设 置 参 数 名 解析 器 
parameter .initParameterNameDiscovery (this.parameterNameDiscoverer); 
// 给 parameter 设 置 containingClass 和 parameterType 
GenericTypeResolver .resolveParameterType (parameter, getBean() .getClass()); 


// 如 果 相 应 类 型 的 参数 已 经 在 providedArgs 中 提供 了 ， 则 直接 设置 到 parameter 


args[i] = resolveProvidedArgument (parameter, providedArgs); 
if (args[i] != null) { 
continue; 


和 
// 使 用 argumentResolvers 解 析 参 数 
if (this.argumentResolvers.supportsParameter (parameter)) { 
try { 
args[i] = this.argumentResolvers.resolveArgument ( 
Parameter, mavContainer, request, this.dataBinderFactory); 
continue; 
} catch (Exception ex) { 
if (logger.isTraceEnabled()) { 
logger.trace (getArgumentResolutionErrorMessage ("Error resolving argument", i), ex); 


throw ex; 


} 


// 如 果 没 解析 出 参数 ， 则 抛 出 异常 
if (args[i] 一 null) { 
String msg = getArgumentResolutionErrorMessage ("No suitable resolver for argument", i); 
throw new IllegalStateException (msg); 
} 
return args; 


} 


通过 注释 大 家 就 容易 理解 了 ， 这 里 首先 调用 父 类 的 getMethodParameters 方 法 获取 到 Method 的 所 有 参数 ， 
析 ， 解 析 的 方法 有 两 种 ， 第 一 种 是 在 providedArgs 里 面 找 ， 第 二 种 是 使 用 argumentResolvers 解 析 ， 在 RequestMappingHandlerAdapter 中 的 调用 并 没有 提供 providedArgs， 所 以 只 有 使 
argumentResolvers 解 析 。 每 个 参数 在 解析 前 都 初始 化 了 三 个 属性 : parameterNameDiscoverer、containingClass 和 parameterType，parameterNameDiscoverer 用 于 获取 参数 名 ， 可 以 在 


后 定义 了 Object 数组 变量 args 用 于 保存 解析 出 的 参数 值 。 接 下 来 遍历 每 个 参数 进行 解 


RequestMappingHandlerAdapter 定 义 时 配置 ， 默 认 使 用 DefaultParameter-NameDiscoverer。containingClass 和 parameterType 在 前 面 已 经 介绍 过 了 ， 分 别 表 示 容 器 类 型 (也 就 是 所 属 的 类 ) 和 参数 


类 型 。 如 果 没有 解析 出 参数 值 最 后 会 抛 出 IllegalStateException 异 常 。 


InvocableHandlerMethod 就 分 析 完 了 ， 它 就 是 在 HandlerMethod 的 基础 上 添加 的 方法 调用 的 功能 ， 而 方法 调用 又 需要 解析 参数 ， 所 以 又 提供 了 解析 参数 的 功能 。 实 际 上 前 面 说 过 的 注释 了 
@InitBinder 的 方法 和 注释 了 @ModelAttribute 的 方法 就 是 封装 成 了 Invocable-HandlerMethod 对 象 ， 然 后 直接 执行 的 。 


13.6.3 ServletlnvocableHandlerMethod 


ServletlnvocableHandlerMethod 继 承 自 InvocableHandlerMethod， 在 父 类 基础 上 增加 了 三 个 功能 : @ 对 @ ResponseStatus 注 释 的 支持 ; @ 对 返回 值 的 处 理 ; @@ 对 异步 处 理 结果 的 处 理 。 


@ResponseStatus 注 释 用 于 处 理 器 方法 或 者 返回 值 上 ， 作 用 是 对 返回 Response 的 Status 进 行 设置 ， 它 有 两 个 参数 : value 和 reason，value 是 HttpStatus 类 型 ， 不 能 为 空 ，reason 是 String 类 型 ， 表 示 
错误 的 原因 ， 默 认为 空 字符 串 (不 是 null) 。 当 一 个 方法 注释 了 @ResponseStatus 后 ， 返 回 的 response 会 使 用 注释 中 的 Status， 如 果 处 理 器 返回 值 为 空 或 者 reason 不 为 空 ， 则 将 中 断 处 理 直 接 返回 (不 再 泻 
染 页 面 ) 。 实 际 环境 中 用 的 并 不 是 很 多 。 


对 返回 值 的 处 理 是 使 用 returnValueHandlers 属 性 完成 的 ， 它 是 HandlerMethodReturn-ValueHandler 类 型 的 属性 。 异 步 处 理 使 用 了 两 个 内 部 子 类 ， 异 步 处 理 的 相关 内 容 后 面 专门 讲解 。 


ServletlnvocableHandlerMethod 处 理 请 求 使 用 的 是 invokeAndHandle 方 法 ， 代 码 如 下 : 


public void invokeAndHandle (ServletWebRequest webReauest， 
ModelAndViewContainer mavContainer, Objecthttp://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/15447/0EBPS/Text/... providedArgs) thrc 
Object returnValue = invokeForRequest (webRequest, mavContainer, providedArgs); 
setResponseStatus (webRequest); 
if (returnValue == null) { 
if (isRequestNotModified (webRequest) || hasResponseStatus () || mavContainer.isRequestHandled()) { 
mavContainer.setRequestHandled (true); 
return; 


} 
lelse if (StringUtils.hasText (this.responseReason)) { 

mavContainer.setRequestHandled (true); 

return; 
} 
mavContainer.setRequestHandled (false); 
try { 

this.returnValueHandlers.handleReturnValue ( 

returnValue, getReturnValueType (returnValue), mavContainer, webRequest); 

}catch (Exception ex) { 

if (logger.isTraceEnabled()) { 

logger .trace (getReturnValueHandlingErrorMessage ("Error handling return value", returnValue), ex); 


throw ex; 


首先 调用 父 类 的 invokeForRequest 执 行 请 求 ， 接 着 处 理 @ResponseStatus 注 释 ， 最 后 处 理 返 回 值 。 处 理 @ResponseStatus 注 释 的 方法 是 setResponseStatus， 它 会 根据 注释 的 值 设置 response 的 相关 
属性 ， 代 码 如 下 : 


Private void setResponseStatus (ServletWebRequest webRequest) throws IOException { 
if (this.responseStatus == null) { 
return; 


i 
if (StringUtils.hasText (this.responseReason)) { 
webRequest .getResponse () .sendError (this.responseStatus.value () ，this.responseReason) 7 
} else { 
webRequest .getResponse () .setStatus (this.responseStatus.value ()); 


} 
// 设置 到 request 的 属性 ， 为 了 在 redirect 中 使 用 
webRequest .getRequest () .setAttribute (View.RESPONSE STATUS ATTRIBUTE, this.responseStatus); 


处 理 返回 值 的 逻辑 是 先 判断 返回 值 是 不 是 null， 如 果 是 null， 只 要 request 的 notModified 为 真 、 注 释 了 @ResponseStatus 和 mavContainer 的 requestHandled 为 true 这 三 项 中 有 一 项 成 立 则 设置 为 请 
求 已 经 处 理 并 返回 ， 如 果 返 回 值 不 为 null， 而 @ResponseStatus 注 释 里 存在 reason， 也 会 将 请 求 设 置 为 已 处 理 并 返回 。 设 置 已 处 理 的 方法 前 面 已 经 讲 过 ， 就 是 设置 mavContainer 的 requestHandled 属 性 
为 true。 如 果 上 面 那些 条 件 都 不 成 立 则 将 mavContainer 的 requestHandled 设 置 为 false， 并 使 用 returnValueHandlers 处 理 返 回 值 。 


到 这 里 调用 处 理 器 处 理 请 求 的 过 程 就 讲 完了 。 接 下 来 分 析 解 析 参 数 的 HandlerMethod-ArgumentResolver 和 处 理 返回 值 的 HandlerMethodReturnValueHandler。 


13.7 HandlerMethodArgumentResolver 


HandlerMethodArgumentResolver 是 用 来 为 处 理 器 解析 参数 的 ， 主 要 用 在 前 面 讲 过 的 InvocableHandler-Method 中 。 每 个 Resolver 对 应 一 种 类 型 的 参数 ， 所 以 它 的 实现 类 非常 多 ， 其 继承 结构 如 图 
13-5 所 示 。 
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图 13-5 HandlerMethodArgumentResolver 继 承 结 构图 


这 里 有 一 个 实现 类 比较 特殊 ， 那 就 是 HandlerMethodArgumentResolverComposite， 它 不 具体 解析 参数 ， 而 是 可 以 将 多 个 别 的 解析 器 包含 在 其 中 ， 解 析 时 调用 其 所 包含 的 解析 器 具体 解析 参数 ， 这 种 
模式 在 前 面 已 经 见 过 好 几 次 了 ， 在 此 就 不 多 说 了 。 下 面 来 看 一 下 HandlerMethodArgumentResolver 接 口 的 定义 : 


package org.s Sh nro rk.web.method.support; 
// 省 We orts 
public interface HandlerMethodArgumentResolver { 
olean sul Dor eb a r (Met] eter); 
Object resolveArgument (MethodParameter parameter, ModelAnav ewContai mavContainer 
NativeWebRequest webRequest, WebDataBil oe rFactory binderFactory) "eh rows Exception 
} 


非常 简单 ， 只 有 两 个 方法 ， 一 个 用 于 判断 是 否 可 以 解析 传 入 的 参数 ， 另 一 个 就 是 用 于 实际 解析 参数 。 


HandlerMethodArgumentResolver 实 现 类 一 般 有 两 种 命名 方式 ， 一 种 是 XXXMethod-ArgumentResolver， 另 一 种 是 XXXMethodProcessor。 前 者 表示 一 个 参数 解析 器 ， 后 者 除了 可 以 解析 参数 外 还 
可 以 处 理 相应 类 型 的 返回 值 ， 也 就 是 同时 还 是 后 面 要 讲 到 的 Handler-Method-ReturnValueHandle。 其 中 的 XXX 表示 用 于 解析 的 参数 的 类 型 。 另 外 ， 还 有 个 Adapter， 它 也 不 是 直接 解析 参数 的 ， 而 是 用 来 
兼容 WebArgumentResolver 类 型 的 参数 解析 器 的 适配器 。 


下 面 依次 介绍 这 些 解析 器 : 


“ AbstractMessageConverterMethodArgumentResolver: 使 用 HttpMessageConverter 解 析 request body 类 型 参数 的 基 类 。 

“ AbstractMessageConverterMethodProcessor: 定义 相关 工具 ， 不 直接 解析 参数 。 

“ HttpEntityMethodProcessor: 解析 HttpEntity 和 RequestEntity 类 型 的 参数 。 

:RequestResponseBodyMethodProcessor: 解析 注释 @RequestBody 类 型 的 参数 。 

:RequestPartMethodArgumentResolver: 解析 注释 了 @RequestPart、MultipartFile 类 型 以 及 javax.setvlethttp.Part 类 型 的 参数 。 


“ AbstractNamedValueMethodArgumentResolver: 解析 namedValue 类 型 的 参数 (有 name 的 参数 ， 如 cookie、requestParam、requestHeader、pathVariable 等 ) 的 基 类 ， 主 要 功能 有 : 四 获取 name; 
@resolveDefaultValue、handleMissingValue、handleNullValue; @@) 调 用 模板 方法 resolveName、handleResolvedValue 具 体 解析 。 


:AbstractCookieValueMethodArgumentResolver: 解析 注释 了 @CookieValue 的 参数 的 基 类 。 

“ServletCookieValueMethodArgumentResolver: 实现 resolveName 方 法 ， 具 体 解 析 cookieValue。 

“ ExpressionValueMethodArgumentResolver: 解析 注释 @Value 表 达 式 的 参数 ， 主 要 设置 了 beanFactorty， 并 用 它 完成 具体 解析 ， 解 析 过 程 在 父 类 完成 。 
MatrixVariableMethodArgumentResolver: 解析 注释 @MatrixVariable 而 且 不 是 Map 类 型 的 参数 (Map 类 型 使 用 MatrixVariableMapMethodArgumentResolver 解 析 ) 。 

“ PathVariableMethodArgumentResolver: 解析 注释 (@PathVariable 而 且 不 是 Map 类 型 的 参数 (Map 类 型 则 使 用 PathVariableMapMethodArgumentResolver 解 析 ) 。 
.RequestHeaderMethodArgumentResolver: 解析 注释 了 (@RequestHeadet 而 且 不 是 Map 类 型 的 参数 (Map 类 型 则 使 用 RequestHeaderMapMethodArgumentResolver 解 析 ) 。 


“ RequestParamMethodArgumentResolver: 可 以 解析 注释 了 (@RequestParam 的 参数 、MultipartFile 类 型 的 参数 和 没有 注释 的 通用 类 型 (如 int、long 等 ) 的 参数 。 如 果 是 注释 了 (@RequestParam 的 Map 类 型 的 参 
数 ， 则 注释 必须 有 name 值 (否则 使 用 RequestParamMapMethodArgumentResolver 解 析 ) 。 


' AbstractWebArgumentResolverAdapter: 用 作 WebArgumentResolver 解 析 器 的 适配器 。 
“ ServletWebArgumentResolverAdapte: 给 父 类 提供 了 request。 


“ ErrorsMethodArgumentResolver: 解析 Errors 类 型 的 参数 (一 般 是 Errors 或 Binding-Result) ， 当 一 个 参数 绑 定 出 现 异 常 时 会 自动 将 异常 设置 到 其 相 邻 的 下 一 个 Errors 类 型 的 参数 ， 设 置 方法 就 是 使 用 了 这 个 
解析 器 ， 内 部 是 直接 从 model 中 获取 的 。 


“ HandlerMethodArgumentResolverComposite: argumentResolver 的 容器 ， 可 以 封装 多 个 Resolver， 具 体 解 析 由 封装 的 Resolver 完 成 ， 主 要 为 了 方便 调用 。 
“ MapMethodProcessor: 解析 Map 型 参数 (包括 ModelMap 类 型 ) ， 直 接 返 回 mav-Container 中 的 model。 
MatrixVariableMapMethodArgumentResolver: 解析 注释 了 @MatrixVariable 的 Map 类 型 参数 。 


:ModelAttributeMethodProcessor: 解析 注释 了 @ModelAttribute 的 参数 ， 如 果 其 中 的 annotationNotRequired 属 性 为 true 还 可 以 解析 没有 注释 的 非 通用 类 型 的 参数 (RequestParamMethodAregumentResolver 解 析 
没有 注释 的 通用 类 型 的 参数 ) 。 


“ ServletModelAttributeMethodProcessor: 对 父 类 添加 了 Servlet 特 性 ， 使 用 Servlet-RequestDataBinder 代 替 父 类 的 WebDataBinder 进 行 参数 的 绑 定 。 

ModelMethodProcessor: 解析 Model 类 型 参数 ， 直 接 返回 mavContainet 中 的 model。 

“ PathVariableMapMethodArgumentResolver: 解析 注释 了 @PathVariable 的 Map 类 型 的 参数 。 

: RedirectAttributesMethodAregumentResolver: 解析 RedirectAttributes 类 型 的 参数 ， 新 建 RedirectAttributesModelMap 类 型 的 ReditrectAttributes 并 设置 到 mavContainet 中 ， 然 后 返回 给 我 们 的 参数 。 
“ RequestHeaderMapMethodArgumentResolver: 解析 注释 了 (@RequestHeader 的 Map 类 型 的 参数 。 

“ RequestParamMapMethodArgumentResolver: 解析 注释 了 (@RequestParam 的 Map 类 型 ， 而且 注 释 中 有 value 的 参数 。 


“ ServletRequestMethodArgumentResolver: 解析 WebRequest、ServletRequest、Multipart-Request、HttpSession、Principal、Locale、TimeZone、InputStream、Reader、HttpMethod 类 型 和 "java.time.Zoneld" 类 型 
的 参数 ， 它 们 都 是 使 用 request 获 取 的 。 


“ ServletResponseMethodArgumentResolver: 解析 ServletResponse、OutputStream、 Wtriter 类 型 的 参数 。 
“SessionStatusMethodArgumentResolver: 解析 SessionStatus 类 型 参数 ,直接 返回 mavContainer 中 的 SessionStatus。 


“ UriComponentsBuilderMethodArgumentResolver: 解析 UriComponentsBuilder 类 型 的 参数 。 


由 于 解析 器 的 数量 太 多 ， 在 此 就 不 对 每 一 个 都 详细 分 析 了 ， 那 样 也 没有 必要 ， 我 们 找 两 个 常用 到 的 来 分 析 ， 让 大 家 知道 里 面 是 怎么 解析 的 ， 如 果 大 家 对 哪个 类 型 的 参数 解析 过 程 感 兴趣 ， 可 以 先 在 上 面 
找到 对 应 的 处 理 器 然后 自己 去 查看 相应 的 源码 。 


下 面 来 分 析 一 下 解析 Model 类 型 参数 的 ModelMethodProcessor 解 析 器 和 解析 注释 了 @PathVariable 的 参数 类 型 的 PathVariableMethodArgumentResolver 解 析 器 ， 这 两 种 类 型 的 参数 使 用 得 非常 


多 。 


ModelMethodProcessor 既 可 以 解析 参数 也 可 以 处 理 返回 值 ， 下 面 为 解析 参数 相关 的 代码 : 


Package org.springframework.web.method.annotation; 
// 省 略 了 imports 
public class ModelMethodProcessor implements HandlerMethodArgumentResolver, HandlerMethodReturnValueHandler { 
QOverride 
public boolean supportsParameter (MethodParameter parameter) { 
return Model.class.isAssignableFrom (parameter .getParameterType () ) 7 
} 
QOverride 
public Object resolveArgument (MethodParameter parameter, ModelAndViewContainer mavContainer, 
NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception { 
return mavContainer.getModel (); 


回 


可 以 看 到 这 个 实现 非常 简单 ，supportsParameter 方 法 判断 如 果 是 Model 类 型 就 可 以 ，resolveArgument 方 法 是 直接 返回 mavContainer 里 的 Model。 通 过 前 面 的 分 析 知 道 ， 这 时 的 Model 可 能 已 经 保 


存 了 一 些 值 ， 如 SessionAttribute 中 的 值 、FlashMap 中 的 值 等 ， 所 以 在 处 理 器 中 如 果 定 义 了 Model 类 型 的 参数 ， 给 我 们 传 的 Model 中 可 能 已 经 保存 的 有 值 了 。 


再 来 看 一 下 PathVariableMethodArgumentResolver， 它 用 于 解析 ur 路径 中 的 值 ， 它 的 实现 比较 复杂 ， 它 继承 自 AbstractNamedValueMethodArgumentResolver， 前 面 介绍 过 这 个 解析 器 是 处 理 


namedValue 类 型 参数 的 基 类 ，cookie、requestParam、requestHeader、pathVariable 等 类 型 参数 的 解析 器 都 继承 自 它 ， 它 跟 我 们 之 前 讲 过 的 很 多 组 件 一 样 ， 使 用 的 也 是 模板 模式 。 其 中 没有 实现 
supportsParameter 方 法 ， 只 实现 了 resolveArgument 方 法 ， 代 码 如 下 : 


// org.springframework.web.method.annotation.AbstractNamedValueMethodArgumentResolver 
public final Object resolveArgument (MethodParameter parameter, ModelAndViewContainer mavContainer, 
NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception { 


// 获取 参数 类 型 
Class<?> paramType = parameter.getParameterType () 7 
// 根据 参数 类 型 获取 NamedValueInfo 


NamedValueInfo namedValueInfo = getNamedValueInfo (parameter); 


// 具体 解析 参数 ， 是 模板 方法 ， 在 子 类 实现 


Object arg = resolveName (namedValueInfo.name, parameter, webRequest); 


// 如 果 没 有 解析 到 参数 
if (arg 一 null) { 
if (namedValueInfo.defaultValue != null) { 


arg = resolveDefaultValue (namedValueInfo.defaultValue); 
} else if (namedValueInfo.required && !parameter.getParameterType() .getName () .equals ("java.util.Optional")) { 
handleMissingValue (namedValueInfo.name, parameter); 


} 


arg = handleNullValue (namedValueInfo.name, arg, 


paramType); 


} else if ("".equals(arg) && namedValueInfo.defaultValue != null) { 
arg = resolveDefaultValue (namedValueInfo.defaultValue); 


} 
// 如 果 binderFactory 不 为 空 ， 则 用 它 创 建 binder 并 转换 解析 出 
if (binderFactory != null) { 


的 参数 (如 果 需 要 转换 ) 


WebDataBinder binder = binderFactory.createBinder (webRequest, null, namedValueInfo.name); 


arg = binder.convertIfNecessary (arg, paramType, 


} 
// 对 解析 出 的 参数 进行 后 置 处 理 


parameter); 


handleResolvedValue (arg, namedValueInfo.name, parameter, mavContainer, webRequest); 


return arg; 


通过 注释 大 家 可 以 看 到 ， 首 先 根据 参数 类 型 获取 到 NamedValuelnfo， 然 后 将 它 传 入 模板 方法 resolveName 由 子 类 具体 解析 ， 最 后 对 解析 的 结果 进行 处 理 。 这 里 用 到 的 Named-Valuelnfo 是 一 个 内 部 


类 ， 其 中 包含 的 三 个 属性 分 别 表示 参数 名 、 是 否 必须 存在 和 默认 值 ， 


定义 如 下 : 


// org.springframework.web.method.annotation.AbstractNamedValueMethodArgumentResolver 


protected static class NamedValueInfo { 
private final String name; 
private final boolean required; 
private final String defaultValue; 


public NamedValueInfo (String name, boolean required, String defaultValue) { 


this.name = name; 
this.required = required; 
this.defaultValue = defaultValue; 


下 面 解释 对 解析 出 的 结果 处 理 的 过 程 ， 首 先 判断 解析 出 的 结果 是 否 为 null 或 者 空 字符 
解析 出 的 结果 为 null 也 没有 默认 值 而 且 namedValuelnfo 中 设置 了 required 为 true 则 调用 handleMissingValue 方 法 ， 这 也 是 模板 方法 ， 在 子 类 实现 ， 然 后 调用 handleNullValue 处 理 null 返 


， 如 果 是 则 判断 NamedValuelnfo 是 否 包含 默 认 值 ， 如 果 包 含 则 调用 resolveDefaultValue 方 法 设置 默认 值 ， 如 果 
值 。 接 下 来 判 


由 


回 


断 binderFactory 是 否 为 空 ， 如 果 不 为 空 则 用 它 创 建 binder 并 转换 解析 出 的 参数 (如 果 需 要 转换 ) ， 最 后 调用 handleResolvedValue 处 理解 析出 的 参数 值 ， 这 也 是 个 模板 方法 ， 在 子 类 实现 。 这 里 的 逻辑 描 


述 起 来 有 点 复杂 ， 直 接 看 代码 其 实 很 容易 理解 。 


下 面 再 总 结 一 下 resolveArgument 过 程 中 所 使 用 的 方法 ， 理 解 了 这 些 方法 这 里 的 处 理 过 程 就 容易 理解 了 。 


1) getNamedValuelnfo 方 法 通过 参数 类 型 获取 NamedValuelnfo， 有 具体 过 程 是 先 从 缓存 中 获取 ， 如 果 获 取 不 到 则 调用 createNamedValuelnfo 方 法 根据 参数 创建 ，createNamedValuelnfo 是 一 个 模 
板 方 法 ， 在 子 类 实现 ， 创 建 出 来 后 调用 updateNamedValuelnfo 更 新 NamedValuelnfo， 最 后 保存 到 缓存 namedValuelnfoCache 中 。updateNamedValuelnfo 方 法 具有 两 个 功能 : @ 如 果 name 为 空 则 


使 用 parameter 的 name; @ 如 果 默 认 值 是 代表 没有 的 ValueConstants.DEFAULT_NONE 类 型 则 设置 为 null。 


// org.springframework.web.method.annotation.AbstractNamedValueMethodArgumentResolver 
Private NamedValueInfo getNamedValueInfo (MethodParameter parameter) { 
NamedValueInfo namedValueInfo = this.namedValueInfoCache.get (parameter); 


if (namedValueInfo == null) { 
namedValueInfo = createNamedValueInfo (parameter 
namedValueInfo = updateNamedValueInfo (parameter 


); 


, namedValueInfo); 


this.namedValueInfoCache .put (parameter, namedValueInfo); 


} 


return namedValueInfo; 


createNamedValuelnfo 在 子 类 PathVariableMethodArgumentResolver 的 实现 是 根据 @PathVariable 注 释 创 建 的 ， 这 里 使 用 了 继承 自 NamedValuelnfo 的 内 部 类 PathVariable-NamedValuelnfo， 


在 PathVariableNamedValuelnfo 的 构造 方法 里 使 用 @PathVariable 注 释 的 value 值 创建 了 NamedValuelnfo， 默 认 required 为 true， 也 就 是 必须 存在 ， 如 果 没 解析 到 值 会 抛 异常 ，defaultValue 使 用 了 


ValueConstants.DEFAULT_NONE， 这 是 一 个 专门 用 来 代表 空 默认 值 的 变量 ， 代 码 如 下 : 


// org.spPringframework.web.servVlet.mvc.method.annotatio 


n.PathVariableMethodArgumentResolver 


protected NamedValueInfo createNamedValueInfo (MethodParameter parameter) { 
PathVariable annotation = parameter.getParameterAnnotation (PathVariable.class); 


return new PathVariableNamedValueInfo (annotation); 


i 


Private static class PathVariableNamedValueInfo extends 


NamedValueInfo { 


public PathVariableNamedValueInfo (PathVariable annotation) { 


super (annotation.value(), true, ValueConstants. 


DEFAULT NONE); 


2) resolveName， 这 个 方法 用 于 具体 解析 参数 ， 是 个 模板 方法 ，PathVariableMethodArgumentResolver 中 实现 如 下 : 


// org.springframework.web.servlet .mvc.method.annotation.PathVariableMethodArgumentResolver 
protected Object resolveName (String name, MethodParameter parameter, NativeWebRequest request) throws Exception { 


Map<String, String> uriTemplateVars = 
(Map<String, String>) request.getAttribute( 


HandlerMapping.URI TEMPLATE VARIABLES ATTRIBUTE, RequestAttributes.SCOPE REQUEST); 


return (uriTemplateVars != null) ? uriTemplateVars. 


get (name) : null; 


可 以 看 到 它 是 直接 从 request 里 获取 的 HandlerMapping.URI_TEMPLATE_VARIABLES_ATTRIBUTE 属 性 的 值 ， 这 个 值 是 在 RequestMappinglnfoHandlerMapping 中 的 handleMatch 中 设置 的 ， 也 就 
是 在 HandlerMapping 中 根据 lookupPath 找 到 处 理 请 求 的 处 理 器 后 设置 的 。 


3) resolveDefaultValue， 这 个 方法 是 根据 NamedValuelnfo 里 的 defaultValue 设 置 默 认 值 ， 如 果 包 含 占 位 符 会 将 其 设置 为 相应 的 值 。 


4) handleMissingValue， 如 果 参 数 是 必须 存在 的 ， 也 就 是 NamedValuelnfo 的 required 为 true， 但 是 没有 解析 出 参数 ， 而 且 也 没有 默认 值 ， 就 会 调用 (如 果 是 java1.8 中 的 Optional 类 型 则 不 调用 ) ， 
这 也 是 个 模板 方法 ，PathVariableMethodArgumentResolver 中 直接 抛 出 了 异常 ， 代 码 如 下 : 


// org.springframework.web.servlet .mve.method.annotation.PathVariableMethodArgumentResolver 
protected void handleMissingValue (String name, MethodParameter parameter) throws ServletRequestBindingException { 
throw new ServletRequestBindingException("Missing URI template variable '" + name + 
"! for method parameter of type " + Parameter.getParameterType () .getSimpleName ()); 


要 用 于 没 解析 


5) handleNullValue， 如 果 解 析 结 果 为 null， 而 且 也 没有 默认 值 ， 并 且 handleMissingValue 没 调用 或 者 调用 了 但 没 抛 异常 的 情况 下 才 会 执行 ， 可 见 这 个 方法 执行 的 机 会 是 比较 小 的 ， 
出 参数 值 也 没 默认 值 ， 不 过 是 Optional 类 型 参数 的 情况 。 


它 的 实现 方法 中 首先 判断 所 需 的 参数 是 不 是 Boolean 类 型 ， 如 果 是 则 给 它 设置 为 false， 如 果 是 其 他 原始 的 类 型 (原始 类 型 共 包含 Boolean、Character、Byte、Short、Integer、Long、Float、 
Double 和 Void 九 个 ) 则 抛 出 异常 ， 否 则 直接 返回 。 代 码 如 下 : 


// org.springframework.web.method.annotation.AbstractNamedValueMethodArgumentResolver 
private Object handleNullValue (String name, Object value, Class<?> paramType) { 
if (value == null) { 
if (Boolean.TYPE.equals (paramType)) { 
return Boolean.FALSE; 
} 
else if (paramType.isPrimitive()) { 
throw new IllegalStateException ("Optional " + paramType + " parameter '" + name + 
"' is present but cannot be translated into a null Value due to being declared as a "+ 
"primitive type. Consider declaring it as object wrapper for the corresponding primitive type."); 


} 


return value; 


加 


也 就 是 说 如 果 是 原始 类 型 (除了 Boolean) ， 即 使 是 Optional 类 型 (如 Optional<Double> ) 也 会 抛 出 异常 ， 这 是 因为 原始 类 型 不 可 以 转换 为 null， 如 果 想 不 抛 异常 可 以 通过 对 应 的 包装 类 型 进行 声 


明 , 如 Optional<double>， 这 样 就 不 会 抛 异常 了 。 


6) handleResolvedValue， 用 于 处 理解 析出 的 参数 值 ， 是 模板 方法 ，PathVariableMethodArgumentResolver 中 实现 如 下 : 


// org.springframework.web.servlet .mvc.method.annotation.PathVariableMethodArgumentResolver 
protected void handleResolvedValue (Object arg, String name, MethodParameter parameter, 
ModelAndViewContainer mavContainer, NativeWebRequest request) { 
String key = View.PATH VARIABLES; 
int scope = RequestAttributes.SCOPE REQUEST; 
Map<String, Object> pathVars = (Map<String, Object>) request.getAttribute (key, scope); 
if (pathVars == null) { 
pathVars = new HashMap<String, Object>(); 
request .setAttribute (key, pathVars, scope); 
i 
pathVars.put (name, arg); 


这 里 的 功能 是 将 解析 出 的 PathVariable 设 置 到 了 request 的 属性 中 ， 方 便 以 后 (如 View 中 ) 使 用 。 


PathVariableMethodArgumentResolver 就 分 析 到 这 里 ， 通 过 这 两 个 处 理 器 的 分 析 大 家 应 该 已 经 可 以 理解 HandlerMethodArgumentResolver 的 工作 原理 了 。 其 实 非 常 简单 ， 里 面 就 两 个 方 
法 ，supportsParameter 用 于 判断 是 否 支 持 所 传 入 的 参数 ，resolveArgument 用 于 解析 出 参数 值 ， 而 具体 解析 过 程 是 从 哪里 获取 参数 值 的 并 没有 什么 通用 的 模式 ， 只 要 最 后 按 类 型 返回 相应 的 值 就 可 以 了 。 


多 知道 点 


PathVariable 和 MatrixVariable 的 使 用 方法 
PathVariable 和 MatrixVariable 的 使 用 让 Spring MVC 变 得 非常 灵活 。 相 信 很 多 读者 对 PathVariable 并 不 陌生 ， 它 使 用 得 非常 多 ， 而 且 用 起 来 也 非常 方便 ， 同 时 PathVariable 也 是 Spring MVC 的 众多 优势 之 一 。 
PathVariable 的 作用 是 将 ufl 作 为 模板 ， 可 以 获取 里 面 的 参数 ， 这 里 的 参数 并 不 是 问号 后 面 传递 的 参数 ( 那 种 参数 使 用 (@RequestParam 注 释 定 义 或 者 也 可 以 不 使 用 注释 ) ， 而 是 ul 本 身 路 径 中 的 参数 ， 我 们 来 看 几 
个 例子 。 


// Get /students/176 
@RequestMapping (value={"/students/{studentId}"},method= {RequestMethod.GET}) 
public void getStudent (@PathVariable String studentId) 1{ 
// studentId = 176 
} 
// Get /students/176/books/7 
@RequestMapping (value={"/students/{studentId} /books/ {bookId}"},method= {RequestMethod.GET}) 
public void getStudentBook (QPathVariable String bookId, @PathVariable String studentId){ 
// studentId = 176, bookId = 7 
} 
// Get /books/7 
@RequestMapping (value={"/books/{id}"},method= {RequestMethod.GET}) 
public void getBook (@PathVariable ("id") String bookId){ 
// bookId = 7 
} 


通过 这 三 个 例子 大 家 就 可 以 明白 (@PathVariable 的 用 法 ， 需 要 注意 的 是 ， 参 数 解 析 的 时 候 并 不 是 按照 叫 里 边 参 数 的 顺序 给 PathVariable 设 置 值 的 ， 比 如 ， 上 面 的 第 二 个 例子 中 参数 和 模板 里 的 顺序 调换 后 仍 
然 可 以 正确 解析 ， 第 三 个 例子 中 ul 模板 中 的 参数 名 与 变量 名 不 同 ， 这 时 通过 注释 里 的 value 值 也 可 以 正确 解析 。 


其 实 通 过 前 面 对 PathVariableMethodArgumentResolver 的 分 析 就 不 难 理解 这 个 结果 了 ， 参 数 的 解析 是 根据 getrNamedValueInfo 获 取 到 的 NamedValueInfo 中 的 name 查 找 的 ， 在 第 一 次 调用 时 会 创建 一 个 
NamedValueInfo， 创 建 时 将 @PathVariable 中 的 value 作 为 了 name， 创 建 完成 后 在 updateNamedValueInfo 中 判断 name 是 否 为 空 ， 如 果 为 空 则 将 参数 名 设置 为 name。 所 以 查找 的 逻辑 是 如 果 人 @PathVariable 注 释 中 设置 
了 value 就 按 value 查 找 ， 否 则 按 参数 名 查找 ， 而 跟 参 数 在 utl 中 的 顺序 没有 任何 关系 。 


因为 updateNamedValueInfo 方 法 定义 在 AbstractNamedValueMethodArgumentResolver 中 ， 所 以 这 个 规则 不 仅 适用 于 PathVariable， 还 适用 于 cookie、trequestParam、trequestHeader 以 及 下 面 要 说 的 MatrixVatiable 等 


NamedValue 类 型 的 属性 。 


MatrixVariable 也 是 utl 中 的 参数 ， 不 过 它 不 是 ul 中 的 一 个 值 〈 两 个 斜 枉 “/” 之 间 的 部 分 ) ， 而 是 值 的 一 些 属性 ， 它 通过 分 号 “; ”和 过 号 “; ”设置 。 比 如 ， 有 个 查 电话 本 的 处 理 器 ， 名 字 通 过 


PathVariable 类 型 的 neme 传 递 。 


// Get /telephoneNumbers/liyang 
@RequestMapping (value={"/telephoneNumbers/ {name}"},method= {RequestMethod.GET}) 
public void getTel (@PathVariable String name){ 
// name = liyang 
} 


一 般 情况 这 样 就 可 以 了 ， 但 有 了 时候 却 不 能 满足 要 求 ， 比 如 ， 上 学 时 我 们 班 有 两 个 叫 李 阳 的 ， 而 且 一 男 一 女 ， 如 果 只 是 根据 name 查 找 就 不 知道 找 哪个 了 ， 这 时 就 可 以 使 用 Matrix-Variable 了， 它 是 通过 在 


name 后 面 加 分 号 后 设置 的 参数 ， 比 如 ， 下 面 的 代码 使 用 了 性 别 属性 。 


// Get /telephoneNumbers/liyang;gender=male 

@RequestMapping (value={"/telephoneNumbers/ {name}"},method= {RequestMethod.GET}) 

public void getTel (GPathVariable String name, @MatrixVariable String gender){ 
// name=liyang gender=male 

} 


后 来 发 现 又 有 个 叫 李 阳 的 英语 老师 ， 这 时 又 不 能 满足 要 求 了 ， 因 为 叫 李 阳 的 男性 还 有 两 个 ， 还 不 能 确定 是 哪个 。 我 们 可 以 再 接着 往 上 加 属性 ， 比 如 ， 可 以 再 添加 个 group 属 性 〈 也 就 是 说 一 个 PathVariable 
可 以 有 不 止 一 个 属性 ， 它 们 都 是 用 分 号 分 割 ) 。 


// Get /telephoneNumbers/liyang;gender=male;group=englishTeacher 

Q@RequestMapping (value={"/telephoneNumbers/ {name}"},method= {RequestMethod.GET}) 

public void getTel (@PathVariable String name,@MatrixVariable String gender, @MatrixVariable String group){ 
// name=liyang gender=male group=englishTeacher 

} 


现在 问题 就 解决 了 。 不 过 这 时 候 使 用 起 来 就 麻烦 了 ， 如 果 想 找 一 个 人 还 得 首先 知道 它 的 性 别 和 属于 哪个 群 组 ， 否 则 调用 请 求 就 会 出 错 。 对 这 个 问题 有 两 种 解决 方案 ， 一 种 是 设置 默认 值 ， 另 一 种 是 给 属 
性 设置 成 不 是 必须 有 的 ， 也 就 是 required 设 为 filse， 它 们 的 设置 都 是 在 @MatrixVatiable 注 释 中 ， 这 里 使 用 第 二 种 方法 ， 如 下 所 示 : 


// Get /telephoneNumbers/liyang;group=englishTeacher 

@RequestMapping (value={"/telephoneNumbers/ {name}"},method= {RequestMethod.GET}) 

public void getTel (GPathVariable String name, @MatrixVariable (required = false) String gender, @MatrixVariable(required = false) String group){ 
// name=liyang gender=null group=englishTeacher 

} 


这 样 虽然 gender 并 没有 传 参数 ， 但 也 可 以 调用 也 不 报错 了 。 如 果 还 有 别 的 属性 需要 添加 直接 按 相 同 的 方法 添加 就 可 以 了 。 


下 面 再 把 需求 修改 一 下 ， 需 要 先 找 出 手机 然后 再 找 联系 人 ， 代 码 如 下 : 


// Get /telephones/iphone/telephoneNumbers/liyang;group=englishTeacher 
@RequestMapping (value={"/telephones/{telName}/telephoneNumbers/ {name}"},method= {RequestMethod.GET}) 


public void getTel (GPathVariable String telName, @PathVariable String name,@Matrix-Variable (required = false) String gender, @MatrixVariable(required = false) String group){ 
// telName=iphone 


// name=liyang gender=null group=englishTeacher 


电话 当然 也 可 以 添加 属性 ， 这 里 添加 个 和 前 面 不 一 样 的 属性 ， 前 面 的 属性 都 是 只 有 一 个 值 ， 这 里 添加 一 个 可 以 有 多 个 值 的 属性 一 表示 颜色 的 colors 必 性， 在 处 理 器 里 是 一 个 Set 类 型 ， 代 码 如 下 : 


// Get /telephones/xiaomi;colors=black, red,golden/telephoneNumbers/liyang; group=englishTeacher 
@RequestMapping (value={"/telephones/{telName} /telephoneNumbers/{name}"},method= {RequestMethod.GET}) 


public void getTel (@PathVariable String telName, @PathVariable Stringname, @MatrixVariable (required = false) Set<String> colors, @MatrixVariable (required = fal 
// telName=xiaomi colors={black, red,golden} 
// name=liyang gender=null group=englishTeacher 


Set 类 型 的 属性 就 这 么 使 用 ， 首 先 在 处 理 器 中 定义 为 Set 类 型 ， 然 后 在 叫 中 传 参 时 使 用 各 号 将 多 个 值 分 开 。 下 面 再 来 给 电话 添加 一 个 group 属 性 。 添 加 方法 大 家 应 该 都 知道 ， 不 过 这 个 属性 在 联系 人 上 已 经 
使 用 了 ， 这 样 两 个 group 就 重复 了 ， 怎 么 区 分 呢 ? 即使 在 注释 里 配置 value 也 不 行 ， 因 为 它们 都 叫 group。 解 决 方法 是 在 @MatrixVatiable 注 释 里 配置 pathVatr 参 数 ， 指 定 属于 哪个 PathVatiable 的 属性 ， 代 码 如 下 : 


// Get /telephones/xiaomi;colors=black, red,golden; group=note/telephoneNumbers/liyang;group=englishTeacher 

@RequestMapping (value={"/telephones/{telName} /telephoneNumbers/{name}"},method= {RequestMethod.GET}) 

public void getTel (GPathVariable String telName, @MatrixVariable (value="group", pathVar="telName", required = false) String telGroup,Q@PathVariable String name, QMatrixVariable! 
// telName=xiaomi colors={black, red,golden} telGroup=note 
// name=liyang gender=null group=englishTeacher 


除了 前 面 所 说 的 @MatrixVariable 还 有 一 种 使 用 方法 ， 它 可 以 将 所 有 的 MatrixVariable 以 Map 的 形式 保存 在 指定 的 参数 里 面 ， 而 且 还 可 以 通过 pathVar 指 定 具 体 的 PathVariable， 比 如 ， 上 面 的 请 求 可 以 分 别 将 参 
数 保存 在 不 同 的 map 中 ， 而 且 这 时 默认 的 tequired 是 false。 


// Get /telephones/xiaomi;colors=black, red,golden; group=note/telephoneNumbers/liyang;gender=male;group=englishTeacher 
@RequestMapping (value={"/telephones/{telName}/telephoneNumbers/ {name}"},method= {RequestMethod.GET}) 
public void getTel (@MatrixVariable Map<String, String> matrixVars, 
@MatrixVariable (pathVar="telName") Map<String, String> telMatrixVars, 
@MatrixVariable (pathVar="name") Map<String, String> contactMatrixVars){ 
// matrixVars: {colors=[black, red, golden], group=[note, englishTeacher], gender=[male]} 
// telMatrixVars: {colors=[black, red, golden], group=[note]} 
// contactMatrixVars: {gender=[male], group=[englishTeacher]} 


MatrixVariable 的 使 用 会 给 程序 带 来 极 大 的 方便 ， 不 过 现在 使 用 得 还 不 是 很 广 ， 首 先是 因为 很 多 开发 人 员 不 熟悉 这 种 用 法 ， 另 外 配套 设施 也 不 完善 ， 比 如 ， 现 在 如 果 使 用 MatrixVatiable， 一 般 需要 手工 拼接 
utl， 这 也 是 比较 麻烦 的 。 


另外 ， 要 在 Spring MVC 中 使 用 MatrixVariable 必 须 将 RequestMappingHandler-Mapping 中 的 removeSemicolonContent 设 为 包 se， 默 认为 true。 如 果 使 用 mvc: annotation-driven 可 以 简单 通过 <mvc: annotation-driven 


enable-mattrix-vatiables="true"/ > 设置 。 


temoveSemicolonContent 用 于 标示 是 否 删除 ul 中 分 号 相关 的 内 容 ， 它 的 作用 应 该 是 为 了 防止 注入 用 的 。 如 果 对 web 安 全 感 兴趣 ， 有 本 叫 《 白 帽子 讲 Web 安 全 》 的 书写 得 不 错 ， 大 家 可 以 看 一 下 ， 是 吴 坦 清 
编著 的 ， 这 本 书 对 Web 安 全 做 了 系统 介绍 ， 读 完 后 可 以 对 Web 安 全 的 结构 以 及 原理 有 个 整体 的 认识 ， 在 脑子 里 建立 了 整体 的 结构 后 如 果 对 某 方面 想 深 入 学 习 可 以 再 查阅 相关 资料 。 


13.8 HandlerMethodReturnValueHandler 


HandlerMethodReturnValueHandler 用 在 ServletlnvocableHandlerMethod 中 ， 作 用 是 处 理 处 理 器 执行 后 的 返回 值 ， 主 要 有 三 个 功能 : @ 将 相应 参数 添加 到 Model; @ 设 置 View; @ 如 果 请 求 已 经 
处 理 完 则 设置 ModelAndViewContainer 的 requestHandled 为 true。 


HandlerMethodReturnValueHandler 的 使 用 方式 与 HandlerMethodArgumentResolver 非 常 相 似 ， 接 口 里 也 是 两 个 方法 ， 一 个 用 于 判断 是 否 支 持 ， 一 个 上 


于 具体 处 理 返 回 值 ， 接 口 定义 如 下 : 


package org.springframework.web.method.support; 
import org.springframework.core.MethodParameter; 
import org.springframework.web.context .request .NativeWebRequest; 
public interface HandlerMethodReturnValueHandler { 
boolean supportsReturnType (MethodParameter returnType); 
void handleReturnValue (Object returnValue, MethodParameter returnType, 
ModelAndViewContainer mavContainer, NativeWebRequest webRequest) throws Exception; 


} 


实现 类 中 也 有 一 个 特殊 的 类 ， 那 就 是 HandlerMethodReturnValueHandlerComposite， 它 和 前 面 说 的 HandlerMethodArgumentResolverComposite 功 能 相同 ， 自 己 不 具体 处 理 返 回 值 ， 而 是 使 用 
内 部 封装 的 组 件 进行 处 理 。 其 他 实现 类 都 和 具体 返回 值 类 型 相对 应 ， 继 承 结构 如 图 13-6 所 示 。 
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图 13-6 ”HandlerMethodReturnValueHandler 继 承 结构 


下 面 依次 介绍 这 些 处 理 器 : 
AbstractMessageConverterMethodProcessor; 处 理 返 回 值 需要 使 用 HttpMessageConverter 写 入 esponse 的 基 类 ， 自 己 并 未 具体 做 处 理 ， 而 是 定义 了 相关 工具 。 
“ HttpEntityMethodProcessor: 处 理 HttpEntity 类 型 ， 并 且 不 是 RequestEntity 类 型 的 返回 值 。 
RequestResponseBodyMethodProcessor: 处 理 当 返回 值 或 者 处 理 请 求 的 Handler 类 注释 了 (@ResponseBody 情 况 下 的 返回 值 。 
“ AsyncTaskMethodReturnValueHandler: 处 理 WebAsyncTask 类 型 的 返回 值 ， 用 于 异步 请 求 ， 使 用 WebAsyncManager 完 成 。 
“ CallableMethodReturnValueHandler: 处 理 Callable 类 型 的 返回 值 ， 用 于 异步 请 求 ， 使 用 WebAsyncManager 完 成 。 
: DeferredResultMethodReturnValueHandler: 处 理 DeferredResult 类 型 的 返回 值 ， 用 于 异步 请 求 ， 使 用 WebAsyncManaget 完 成 。 
: HandlerMethodReturnValueHandlerComposite: 用 于 封装 其 他 处 理 器 ， 方 便 调用 。 
“ HttpHeadersReturnValueHandler: 处 理 HttpHeaders 类 型 的 返回 值 ， 将 HttpHeaders 的 返回 值 添加 到 response 的 Headers 并 设置 mavContainer 的 requestHandled 为 true。 
“ ListenableFutureReturnValueHandler: 处 理 ListenableFuture 类 型 的 返回 值 ， 用 于 异步 请 求 ， 使 用 WebAsyncManager 完 成 。 
“ MapMethodProcessor: 处 理 Map 类 型 的 返回 值 ， 将 Map 添 加 到 mavContainer 的 Model 中 。 


' ModelAndViewMethodReturnValueHandler: 处 理 ModelAndView 类 型 的 返回 值 ， 将 返回 值 中 的 View 和 Model 设 置 到 mavContainer 中 。 


:ModelAndViewResolverMethodReturnValueHandler: 可 以 处 理 所 有 返回 值 ， 一 般 设 置 在 最 后 一 个 ， 当 别 的 处 理 器 都 不 能 处 理 时 使 用 它 处 理 。 它 内 部 封装 了 一 个 List 类 型 的 ModelAndViewResolver 和 一 个 
annotationNotRequired 为 true 的 ModelAttribute-MethodProcessor，ModelAndViewResolver 是 一 个 将 返回 值 解析 为 ModelAndView 类 型 的 通用 接口 ， 可 以 自 定义 后 配置 到 RequestMappingHandlerAdapter 中 。 处 理 返 回 
值 时 先 遍 历 所 有 的 ModelAndViewResolver 进 行 处 理 ， 如 果 有 可 以 处 理 的 ， 则 用 它 处 理 并 将 结果 返回 ， 如 果 都 无 法 处 理 则 调用 ModelAttributeMethodProcessor 进 行 处 理 。 


* ModelAttributeMethodProcessor: 处 理 注释 了 (@ModelAttribute 类 型 的 返回 值 ， 如 果 annotationNotRequired 为 true 还 可 以 处 理 没有 注释 的 非 通用 类 型 的 返回 值 。 
“ ServletModelAttributeMethodProcessor: 对 返回 值 的 处 理 同 父 类 ， 这 里 只 是 修改 了 参数 解析 的 功能 ， 未 对 返回 值 处 理 功 能 做 修改 。 
ModelMethodProcessor: 处 理 Model 类 型 返回 值 ， 将 Model 中 的 值 添加 到 mav-Containet 的 Model 中 。 


' ViewMethodReturnValueHandler: 处 理 View 类 型 返回 值 ， 如 果 返 回 值 为 空 直接 返回 ， 否 则 将 返回 值 设 置 到 mavContainet 的 View 中 ， 并 判断 返回 值 是 不 是 reditect 类 型 ， 如 果 是 则 设置 mavContainer 的 


tedirectModelScenario 为 true。 


“ ViewNameMethodReturnValueHandler: 处 理 void 和 String 类 型 返回 值 ， 如 果 返 回 值 为 空 则 直接 返回 ， 否 则 将 返回 值 通过 mavContainer 的 setViewName 方 法 设置 到 其 View 中 ， 并 判断 返回 值 是 不 是 redirect 类 


型 ， 如 果 是 则 设置 mavContainet 的 redirectModelScenario 为 true。 


返回 值 处 理 器 的 实现 非常 简单 ， 这 里 分 析 一 下 使 用 得 最 多 的 ViewNameMethodReturnValueHandler。 


Package org.springframework.web.servlet.mvc.method.annotation; 
// 省略 了 imports 
public class ViewNameMethodReturnValueHandler implements HandlerMethodReturnValueHandler { 
private String[] redirectPatterns; 
public void setRedirectPatterns (Stringhttp://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/15447/0EBPS/Text/... redirectPatterns) { 
this.redirectPatterns = redirectPatterns; 全 


} 
public String[] getRedirectPatterns() { 
return this.redirectPatterns; 
} 
Override 
Public boolean supportsReturnType (MethodParameter returnType) { 
Class<?> paramType = returnType.getParameterType(); 
return (void.class.equals (paramType) || String.class.equals (paramType)); 
i 
QOverride 
public void handleReturnValue (Object returnValue, MethodParameter returnType, 
ModelAndViewContainer mavContainer, NativeWebRequest webRequest) throws Exception { 


if (returnValue == null) { 
return; 

} else if (returnValue instanceof String) { 
String viewName = (String) returnValue; 


mavContainer.setViewName (viewName); 
if (isRedirectViewName (viewName)) { 
mavContainer.setRedirectModelScenario (true); 


} else { 
// should not happen 
throw new UnsupportedOperationException ("Unexpected return type: " 十 
returnType.getParameterType () .getName () + " in method: " + returnType.getMethod()); 
} 
} 
Protected boolean isRedirectViewName (String viewName) { 
if (PatternMatchUtils.simpleMatch (this.redirectPatterns, viewName)) { 
return true; 
} 


return viewName.startsWith ("redirect:"); 


supportsReturnType 里 通过 判断 返回 值 是 不 是 Void 或 String 类 型 来 确定 是 否 支 持 这 种 类 型 返回 值 的 处 理 。 具 体 处 理 的 handleReturnValue 方 法 先 判断 返回 值 是 否 为 null， 如 果 是 则 直接 返回 ， 否 则 设置 
到 mavContainer 的 View 中 ， 并 判断 返回 值 是 不 是 redirect 类 型 ， 如 果 是 则 设置 mavContainer 的 redirectModelScenario 为 true。 如 果 既 不 为 null 也 不 是 String 类 型 则 抛 异常 ， 不 过 因为 只 有 void 和 string 两 
种 类 型 的 返回 值 才 可 以 进来 ， 所 以 正常 不 会 抛 异常 。 


这 里 的 “是 不 是 redirect 类 型 ”专门 使 用 了 一 个 isRedirectViewName 方 法 进行 判断 ， 在 这 个 方法 中 首先 使 用 redirectPatterns 判 断 是 否 匹配 ， 如 果 都 不 匹配 在 看 是 不 是 以 “redirect: ”开头 ， 这 里 的 
redirectPatterns 可 以 自己 来 设置 ， 是 一 个 String 数 组 ， 也 就 是 可 以 设置 多 个 redirect 匹 配 模板 ， 不 过 这 里 匹配 为 redirect 类 型 后 只 是 给 mavContainer 的 redirectModelScenario 标 志 设 置 为 了 true， 并 不 会 
做 实际 处 理 ， 如 果 想 使 用 还 需要 定义 相应 的 View， 挺 麻烦 的 ， 一 般 来 说 默认 的 就 够 了 ， 不 过 这 个 属性 是 Spring 4.1 新 增 的 ， 可 能 以 后 会 有 相应 的 用 途 。 


13.9 处 结 


本 章 详细 分 析 了 Spring MVC 中 的 HandlerAdapter 的 各 种 具体 实现 方式 。Handler-Adapter 的 继承 结构 比较 简单 ， 只 有 5 个 实现 类 ， 
RequestMappingHandlerAdapter 外 ， 另 外 三 个 的 实现 也 非常 简单 ， 不 过 RequestMapping-HandlerAdapter 却 比较 复杂 。 


中 的 一 个 还 被 弃 用 了 ， 而 剩 下 的 4 个 中 除了 


1 


RequestMappingHandlerAdapter 应 该 是 整个 Spring MVC 组 件 中 最 复杂 的 组 件 ， 不 过 如 果 将 它 的 处 理 流程 理解 清楚 并 且 理 解 了 里 面 所 包含 的 组 件 ， 
解析 参数 、 执 行 请 求 和 处 理 返回 值 。 


实 也 非常 简单 。 整 个 处 理 过 程 可 以 分 为 三 步 步 : 


解析 参数 过 程 中 用 到 的 参数 来 源 有 多 个 ， 大 体 可 以 分 为 两 大 类 ， 一 类 从 Model 中 来 ， 另 一 类 从 request 中 来 ， 前 者 通过 FlashMapManager 和 ModelFactory 管 理 。 具 体 解析 过 程 不 同类 型 的 参数 使 用 不 
同 的 HandlerMethodArgumentResolver 进 行 解 析 ， 有 的 Resolver 使 用 了 WebDataBinderFactory 创 建 的 WebDataBinder， 可 以 通过 @IlnitBinder 向 WebDataBinderFactory 中 注册 WebDataBinder。 


执行 请 求 是 用 的 HandlerMethod 的 子 类 ServletlnvocableHandlerMethod (实际 执行 是 InvocableHandlerMethod) 。 


返回 值 是 使 用 HandlerMethodReturnValueHandler 进 行 解析 的 ， 不 同类 型 返回 值 对 应 不 同 的 HandlerMethodReturnValueHandler。 


另外 ， 整 个 处 理 过 程 中 ModelAndViewContainer 起 着 参数 传递 的 作用 。 


如 果 你 现在 可 以 对 上 述 整 个 过 程 在 脑子 里 非常 清晰 地 想 明 白 ， 甚 至 可 以 想 出 重要 的 代码 ， 那 你 对 RequestMappingHandlerAdapter 的 理解 就 过 关 了 ， 如 果 还 不 可 以 ， 建 议 你 再 反 过 头 去 把 这 一 章 多 看 
几 人 遍 ， 想 要 完全 理解 Spring MVC 就 一 定 要 把 这 部 分 弄 明白 ， 非 常 重要 。 


第 14 章 ”ViewResolver 


前 面 已 经 介绍 过 ViewResolver 的 功能 和 用 法 ， 它 主要 的 作用 是 根据 视 


出 


名 和 Locale 解 析出 视图 ， 解 析 过 程 主要 做 两 件 事 : 解析 出 使 用 的 模板 和 视 


区 


的 类 型 。ViewResolver 的 继承 结构 如 图 14-1 所 示 。 


4 风 ViewResolver 
4 O° AbstractCachingViewResolver 

ResourceBundleViewResolver 

UrlBasedViewResolver 

© AbstractTemplateViewResolver 
OG FreeMarkerViewResolver 
OG GroovyMarkupViewResolver 
© VelocityViewResolver 

3 VelocityLayoutViewResolver 
InternalResourceViewResolver 
JasperReportsVilewResolver 
TilesViewResolver 
TilesViewResolver 
XsltVlewResolver 
GO XxmlViewResolver 
BG BeanNameViewResolver 


BO ContentNegotiatingViewResolver 


© ViewResolverComposite 


图 14-1 ViewResolver 继 承 结构 图 


Spring MVC 中 ViewResolver 整 体 可 以 分 为 四 大 类 : AbstractCachingViewResolver、BeanNameViewResolver、ContentNegotiatingViewResolver 和 ViewResolver-Composite。 其 中 后 三 类 每 一 
类 都 只 有 一 个 实现 类 ， 而 AbstractCachingViewResolver 却 一 家 独 大 ， 这 也 难怪 ， 因 为 它 是 所 有 可 以 缓存 解析 过 的 视图 的 基 类 ， 而 逻辑 视图 和 视图 的 关系 一 般 是 不 变 的 ， 所 以 不 需要 每 次 都 重新 解析 ， 最 好 
解析 过 一 次 就 缓存 起 来 。 


在 后 三 类 中 BeanNameViewResolver 是 使 用 逻辑 视图 作为 beanName 从 Spring MVC 容 器 里 查找 ， 前 面 已 经 分 析 过 代码 了 ， 这 里 就 不 再 说 了 。 


ViewResolverComposite 大 家 看 名 字 就 明白 了 ， 它 是 一 个 封装 着 多 个 ViewResolver 的 容器 ， 解 析 视 图 时 遍历 封装 着 的 ViewResolver 具 体 解 析 ， 不 过 这 里 的 ViewResolverComposite 除 了 遍历 成 员 解 析 
视图 外 还 给 成 员 进行 了 必要 的 初始 化 ， 其 中 包括 对 实现 了 ApplicationContextAware 接 口 的 ViewResolver 设 置 ApplicationContext、 给 实现 ServletContextAware 接 口 的 ViewResolver 设 置 ServletContext 
以 及 对 实现 InitializingBean 接 口 的 ViewResolver 调 用 afterPropertiesSet 方 法 。 


Package org.springframework.web.servlet .view; 
// 省 略 了 imports 
public class ViewResolverComposite implements ViewResolver, Ordered, InitializingBean, 
ApplicationContextAware, ServletContextAware { 
Private final List<ViewResolver> viewResolvers = new ArrayList<ViewResolver>(); 
private int order = Ordered.LOWEST PRECEDENCE; 
public void setViewResolvers (List<ViewResolver> viewResolvers) { 
this.viewResolvers.clear (); 
if (!CollectionUtils.isEmpty (viewResolvers)) { 
this.viewResolvers.addAll (viewResolvers); 


} 


public List<ViewResolver> getViewResolvers() { 
return Collections .unmodifiableList (this.viewResolvers); 


} 
public void setOrder(int order) { 
this.order = order; 


QOverride 

public int getOrder() { 
return this.order; 

} 

QOverride 


public void setApplicationContext (ApplicationContext applicationContext) throws BeansException { 


(ViewResolver viewResolver : this.viewResolvers) { 
if (viewResolver instanceof ApplicationContextAware) { 


for 


( (ApplicationContextAware)viewResolver) .setApplicationContext (applicationContext); 


} 
} 
QOverride 
Public void setServletContext (ServletContext servletContext) { 
for (ViewResolver viewResolver : this.viewResolvers) { 
if (viewResolver instanceof ServletContextAware) { 


((ServletContextAware)viewResolver) .setServletContext (servletContext); 


} 
} 
: 
QOverride 
public void afterPropertiesSet () throws Exception { 
for (ViewResolver viewResolver : this.viewResolvers) { 
if (viewResolver instanceof InitializingBean) { 
((InitializingBean) viewResolver) .afterPropertiesSet (); 
} 
} 


QOverride 
public View resolveViewName (String viewName, Locale locale) throws Exception { 
for (ViewResolver viewResolver : this.viewResolvers) { 
View view = viewResolver.resolveViewName (viewName, 
if (view != null) { 
return view; 


locale); 


} 
} 


return null; 


这 里 的 代码 非常 容易 理解 ， 通 过 这 段 代码 大 家 可 以 对 XXXComposite 类 型 的 组 件 理解 得 更 加 深刻 了 。 之 前 多 次 介绍 过 这 种 组 件 ， 但 由 于 它 非 常 简单 所 以 之 前 一 直 也 没 列 过 代码 。 其 实 它 真 正 的 解析 过 程 
就 是 最 后 一 个 方法 resolveViewName， 非 常 简单 。 别 的 方法 都 是 给 所 包含 的 ViewResolver 做 初始 化 的 ， 当 然 还 有 viewResolvers 的 get/set 方 法 和 设置 Order 的 方法 。 


ContentNegotiatingViewResolver 类 比较 复杂 ， 这 里 把 它 和 AbstractCachingViewResolver 系 列 实现 类 单独 进行 分 析 。 


14.1 ContentNegotiatingViewResolver 


ContentNegotiatingViewResolver 解 析 器 的 作 | 


是 在 别 的 解析 器 解析 的 结果 上 增加 了 对 MediaType 和 后 缀 的 支持 ，MediaType 即 媒体 类 型 ， 有 的 地 方 也 叫 Content-Type， 比 如 ， 常 用 的 text/html、 


text/javascript 以 及 表示 上 传 表单 的 multipart/form-data 等 。 对 视图 的 解析 并 不 是 自己 完成 的 而 是 使 
， 可 能 会 解析 出 多 个 视图 ， 然 后 再 使 


[ 


体 视图 解析 是 使 


ContentNegotiatingViewResolver 


request 获 取 MediaType， 也 可 能 会 有 多 个 结果 ， 最 后 对 这 两 个 


体 解析 视 


所 封装 的 ViewResolver 来 进行 的 。 整 个 过 程 是 这 样 的 : 首先 遍历 所 封装 的 ViewResolver 
结果 进行 匹配 查找 出 最 优 的 视图 。 


的 所 封装 的 viewResolvers 属 性 里 的 ViewResolver 来 解析 的 ，viewResolvers 有 两 种 初始 化 方法 ， 一 种 方法 是 手动 设置 ， 另 外 一 种 方法 是 如 果 没 


有 设置 则 自动 获取 spring 容 器 中 除了 它 自 己 外 的 所 有 ViewResolver 并 设置 到 viewResolvers， 如 果 是 手动 设置 的 ， 而 且 不 在 spring 容 器 中 (如果 使 用 的 是 引用 配置 就 会 在 容器 中 ) ， 会 先 对 它 进行 初始 化 ， 代 
码 如 下 : 
//org.springframework.web.servlet .view.ContentNegotiatingViewResolver 
protected void initServletContext (ServletContext servletContext) { 
// 获取 容器 中 所 有 ViewResolver 类 型 的 Dean， 注 意 这 里 是 从 整个 spring 容 器 而 不 只 是 SpringMVC 容 器 中 获取 的 
Collection<ViewResolver> matchingBeans =BeanFactoryUtils.beansOfTypeIncludingAncestors (getApplicationContext (), ViewResolver.class) .values (); 


// 如 果 没 有 手动 注册 则 将 容器 中 找到 的 ViewResolver 设 置 给 viewResolvers 
if (this.viewResolvers = null) { 
this.viewResolvers = new ArrayList<ViewResolver> (matchingBeans.size()); 


for (ViewResolver viewResolver : matchingBeans) { 
if (this != viewResolver) { 
this.viewResolvers.add (viewResolver); 
} 
} 
} else { 


// 如 果 是 手动 注册 的 ， 并 且 在 容器 中 不 存在 ， 则 进行 初始 化 
for (int i=0; i < viewResolvers.size(); i++) { 
if (matchingBeans.contains (viewResolvers.get (i))) { 
continue; 
} 


String name = viewResolvers.get (i) .getClass () .getName () + i; 


getApplicationContext () .getAutowireCapableBeanFactory () .initializeBean (ViewResolvers.get (i), name); 


} 
} 
if (this.viewResolvers.isEmpty()) { 


logger.warn ("Did not find any ViewResolvers to delegate to; Please configure them using the "+ 


mr 


viewResolvers' property on the ContentNegotiatingViewResolver"); 


} 

// 按照 Order 属 性 进行 排序 

OrderComparator. sort (this.viewResolvers); 
this.cnManagerFactoryBean.setServletContext (servletContext); 


解析 视图 的 过 程 在 resolveViewName 方 法 中 ， 如 下 : 


//org.springframework.web.servlet .view.ContentNegotiatingViewResolver 
public View resolveViewName (String viewName, Locale locale) throws Exception { 
// 使 用 RequestContextHolder 获 取 RequestAttributes， 进 而 在 下 面 获取 request 
RequestAttributes attrs = RequestContextHolder .getRequestAttributes (); 
Assert.isInstanceOf (ServletRequestAttributes.class, attrs); 
// 使 用 request 获 取 MediaType， 用 作 需 要 满足 的 条 件 
List<MediaType> requestedMediaTypes = 
if (requestedMediaTypes != null) { 
// 获取 所 有 候选 视图 ， 内 部 通过 遍历 封装 的 viewResolvers 来 解析 
List<View> candidateViews = 
// 从 多 个 候选 视图 中 找 出 最 优 视图 
View bestView = getBestView (candidateViews, requestedMediaTypes, attrs); 
if (bestView != null) { 
return bestView; 
} 
} 
if (this.useNotAcceptableStatusCode) { 
if (logger.isDebugEnabled()) { 


getMediaTypes ( ( (ServletRequestAttributes) attrs) .getRequest ()); 


getCandidateViews (viewName, locale, requestedMediaTypes); 


logger.debug ("No acceptable view found; returning 406 (Not Acceptable) status code"); 


} 
return NOT ACCEPTABLE VIEW; 
jelse { 
logger.debug ("No acceptable view found; returning null"); 
return null; 


通过 注释 大 家 可 以 看 到 ， 整 个 过 程 是 这 样 的 : 首先 使 


使 


的 是 在 前 面 分 析 FrameworkServ 


Ea 


要 满 
清楚 了 可 以 返回 去 


衣 息 


足 的 条 件 ， 然 后 使 


request 获 取 MediaType 作 为 
let 时 介绍 过 的 RequestContextHolder， 如 果 记 不 


viewResolvers 解 析出 


看 一 下 。 接 下 来 看 一 下 获取 候选 视 


哆 | 
哆 | 


时 多 个 候选 视图 ， 最 后 将 两 者 进行 匹配 找 出 最 优 视 | 
的 getCandidateViews 方 法 。 


。 获 取 request 


[ 


//org.sPringframework.web.servlet.view.ContentNegotiatingViewResolver 
private List<View> getCandidateViews (String viewName, Locale locale, List<MediaType> requestedMediaTypes) throws Exception { 


List<View> candidateViews 


for (ViewResolver viewResolver : 
View view = 
if (view != null) { 


viewResolver .resolveViewName (viewName, 


new ArrayList<View>(); 
this.viewResolvers) 


{ 


locale); 


candidateViews .add (view); 


} 
for (MediaType reques 


tedMediaType : requestedMediaTypes) { 


List<String> extensions = this.contentNegotiationManager.resolveFileExtensions (requestedMediaType); 


for (String extension : 
String viewNameWithExtension 


View = ViewRe 


让 


(view != null) 


extensions) { 
ViewName + "." + extension; 
solver .resolveViewName (viewNameWithExtension, 


locale); 


candidateViews .add (view); 


} 
} 


} 
if (!CollectionUtils.isEmpty (this.defaultViews)) 


candidateViews.addAll 
i 


return candidateViews; 


{ 
(this.defaultViews); 


这 里 的 逻辑 也 非常 简单 ， 首 先 遍历 viewResolvers 进 行 视图 解析 ， 并 将 所 有 解析 出 的 结果 添加 到 候选 视图 ， 然 后 判断 有 没有 设置 默认 视图 ， 如 果 有 则 也 将 它 添加 到 候选 视图 。 不 过 这 里 使 有 
viewResolvers 进 行 视图 解析 的 过 程 稍微 有 点 复杂 ， 除 了 直接 使 用 逻辑 视图 进行 解析 ， 还 使 用 了 通过 遍历 requestedMediaTypes 获 取 到 所 对 应 的 后 缀 ， 然 后 添加 到 逻辑 视图 后 面 作为 一 个 新 视图 名 进行 解 
析 。 

解析 出 候选 视图 后 使 用 getBestView 方 法 获取 最 优 视图 ， 代 码 如 下 : 


//org.springframework.web.servlet .view.ContentNegotiatingViewResolver 


private View getBestView (List<View> candidateViews, List<MediaType> requestedMediaTypes, RequestAttributes attrs) 
判断 解 候 选 视图 中 有 没有 redirect 视 图 ， 如 果 有 直接 将 其 返回 


中 
(View candidateView : 
if (candidateView instal 

SmartView smartView 

if (smartView.isRedi 
if (logger.isDebu 
logger.debug (™ 


for 


candidateViews) { 

nceof SmartView) { 

(SmartView) candidateView; 

rectView()) { 

gEnabled()) { 

Returning redirect view [" + candidateView + "]"); 


return candidateView; 


} 
下 
for (MediaType mediaType : 
for 
if (StringUtils.hasT 
MediaType candida 


(View candidateView : 


requestedMediaTypes) { 
candidateViews) { 


ext (candidateView.getContentType())) { 


根据 候选 视图 获取 对 应 的 MediaType 


teContentType 


MediaType .parseMediaType (candidateView. getContentType()); 


{ 


// 判 断 当 前 MediaTyPpe 是 否 支持 从 候选 视图 获取 对 应 的 MediaType， 如 text/* 可 以 支持 Lext/htmL、text/css、text/xml 等 所 有 text 的 类 型 


if (mediaType.isC 


if (logger.isDebugEnabled() 


logger .debu: 


+ mediaType + "7 


ompatibleWith (candidateContentType)) { 


{ 


) 
g ("Returning [" + candidateView + "] based on requested media type '" 


attrs.setAttribute (View.SELECTED CONTENT TYPE, mediaType, RequestAttributes. SCOPE REQUEST); 


return candida 


} 


return null; 


teView; 


首先 判断 解 候选 视 
MediaType， 并 使 


14.2 AbstractCachingVi 


到 中 有 没有 redirect 视 图 ， 如 果 有 直接 将 其 返回 ， 否 则 同时 遍历 从 request 中 获取 的 requestedMediaTypes 和 解析 出 的 候选 逻辑 视图 candidateViews， 然 后 根据 候选 视图 获取 对 应 的 
当前 的 requestedMediaType 对 其 进行 判断 ， 如 果 支 持 则 将 所 用 的 requestedMediaType 添 加 到 request 的 Attribute 中 ， 以 便 在 视图 泻 染 过 程 中 使 用 ， 并 将 当前 视图 返回 。 
ewResolver 系 列 
AbstractCachingViewResolver 提 供 了 统一 的 缓存 功能 ， 当 视图 解析 过 一 次 就 被 缓存 起 来 ， 直 到 缓存 被 删除 前 视图 的 解析 都 会 自动 从 缓存 中 获取 。 
它 的 直接 继承 类 有 三 个 : ResourceBundleViewResolver、XmlViewResolver 和 UrlBased-ViewResolver。 第 一 个 的 用 法 在 前 面 已 经 介绍 过 了 ， 它 是 通过 使 用 properties 属 性 配置 文件 解析 视图 的 ; 第 二 
了 xm 配置 文件 ;第 三 个 是 所 有 直接 将 逻辑 视图 作为 ur| 查 找 模板 文件 的 ViewResolver 的 基 类 ， 因 为 它 设置 了 统一 的 查找 模板 的 规则 ， 所 以 它 的 子 类 只 需要 确定 泻 染 方式 


个 跟 第 一 个 非常 相似 ， 只 不 过 它 使 
也 就 是 视 轿 


前 两 种 解析 器 的 实现 原理 非常 简 和 


的 ， 如 下 : 


类 型 就 可 以 了 ， 它 的 每 一 个 子 类 对 应 一 种 视 


类 型 


[ 


和 E， 首 先 根据 Locale 将 相应 的 配置 文件 初始 化 到 BeanFactory， 然 后 直接 将 逻辑 视 | 


有 查找 就 可 以 了 。 它 们 两 个 的 loadView 的 代码 是 一 样 


作为 beanName 到 factory 生 


//org.springframework.web.servlet .view.ResourceBundleViewResolver 

//org.springframework.web.servlet .view.XmlViewResolver 

Protected View loadView (String viewName, Locale locale) throws BeansException { 
BeanFactory factory = initFactory(); 


try { 


return factory.getBean (viewName, View.class); 


}catch (NoSuchBeanDefinitionException ex) 


return null; 


} 


UrlBasedViewResolver 稍 后 再 详细 分 析 ， 先 来 看 一 下 AbstractCachingViewResolver 中 解析 视 


{ 


出 


的 过 程 ， 代 码 如 下 : 


//org.springframework.web.servlet .view.AbstractCachingViewResolver 
public View resolveViewName (String viewName, Locale locale) throws Exception { 


if (!isCache()) 
// 实 际 创建 视图 


{ 


return createView (viewName, 


} else { 


locale); 


Object cacheKey = getCacheKey (viewName, locale); 
View view = this.viewAccessCache.get (cacheKey); 


if (view ul1) 


本 


synchronized (this.viewCreationCache) 


View 
if (view == null) 


// 创 建 视图 


. 


this.viewCreationCache.get (cacheKey); 


View = createView (viewName, locale); 


if (view == null && this.cacheUnresolved) { 
View = UNRESOLVED VIEW; 
b: 


if (view != null) { 
this.viewAccessCache .put (cacheKey, view); 
this.viewCreationCache.put (cacheKey, view); 
if (logger.isTraceEnabled()) { 
logger.trace ("Cached view [" + cacheKey + "]"); 
} 


} 
i 
return (view != UNRESOLVED VIEW ? view : null); 
} 
} 


Protected View createView (String viewName, Locale locale) throws Exception { 
return loadView (viewName, locale); 
} 


逻辑 非常 简单 ， 首 先 判断 是 否 开启 了 缓存 功能 ， 如 果 没 开启 则 直接 调用 createView 创 建 视图 ， 否 则 检查 是 否 已 经 存在 缓存 中 ， 如 果 存 在 则 直接 获取 并 返 
缓存 中 并 返回 。createView 内 部 直接 调 


了 loadView 方 法 ， 而 loadView 是 一 个 模板 方法 ， 留 给 子 类 实际 创建 视图 ， 这 也 是 子 类 解析 视图 的 入 [ 
板 方 法 让 子 类 使 用 是 因为 在 loadView 前 可 以 统一 做 一 些 通 用 的 解析 ， 如 果 


回 


， 否 则 使 用 createView 创 建 一 个 ， 然 后 保存 到 


方法 。createView 之 所 以 调用 了 loadView 而 没有 直接 作为 模 
田 析 不 到 再 交 给 loadView 执 行 ， 这 点 在 UrlBasedViewResolver 中 有 具体 的 体现 。 


AbstractCachingViewResolver 里 有 个 cacheLimit 参 数 需要 说 一 下 ， 它 是 用 来 设置 最 大 缓存 数 的 ， 当 设置 为 0 时 不 启 
以 缓存 视图 的 数量 ， 如 果 往 里 面 添加 视图 时 超过 了 这 个 数 那么 最 前 


缓存 ，isCache 就 是 判断 它 是否 大 于 0， 如 果 设 置 为 一 个 大 于 0 的 数 则 它 表 示 最 多 可 
面 缓存 的 值 将 会 删除 。cacheLimit 的 默认 值 是 1024， 也 就 是 最 多 可 以 缓存 1024 个 视图 


多 知道 点 


LinkedHashMap 中 的 自动 删除 功能 
LinkedHashMap 中 保存 的 值 是 有 顺序 的 ， 不 过 除了 这 点 还 有 一 个 功能 ， 它 可 以 自动 删除 最 前 面 保存 的 值 ， 这 个 很 多 人 并 不 知道 。 


LinkedHashMap 中 有 一 个 removeEldestEntry 方 法 ， 如 果 这 个 方法 返回 true，Map 中 最 前 面 添加 的 内 容 将 被 删除 ， 它 是 在 添加 属性 的 Put 或 patAll 方 法 被 调用 后 自动 调用 的 。 这 个 功能 主要 是 用 在 缓存 中 ， 用 来 
限定 缓存 的 最 大 数量 ， 以 防止 缓存 无 限 地 增长 。 当 新 的 值 添加 后 ， 如 果 缓 存 达到 了 上 限 ， 最 开头 的 值 就 会 被 删除 ， 当 然 这 需要 设置 ， 设 置 方法 就 是 覆盖 removeEldestEntry 方 法 ， 当 这 个 方法 返回 true 时 就 表示 


达到 了 上 限 ， 返 回 伺 se 就 是 没 达到 上 限 ， 而 size0 方 法 可 以 返回 现在 所 保存 对 象 的 数量 ,一般 用 它 和 设置 的 值 做 比较 就 可 以 了 。AbstractCachingViewResolver 中 的 viewCreationCache 就 是 使 用 的 这 种 方式 ， 代 码 如 
下 : 


//org.springframework.web.servlet .view.AbstractCachingViewResolver 
private final Map<Object, View> viewCreationCache = 
new LinkedHashMap<Object, View> (DEFAULT CACHE LIMIT, 0.75f, true) { 
@Override 和 和 
protected boolean removeEldestEntry (Map.Entry<Object, View> eldest) { 
if (size() > getCacheLimit()) { 
viewAccessCache.remove (eldest .getKey ()); 
return true; 
} else { 
return false; 
} 
} 
}; 


在 AbstractCachingViewResolver 中 使 用 了 两 个 Map 做 缓存 ， 它 们 分 别 是 viewAccessCache 和 viewCreationCache。 前 者 是 ConcurrentHashMap 类 型 ， 它 内 部 使 用 了 细 粒 度 的 锁 ， 
率 非 常 高 ， 而 后 者 主要 提供 了 限制 缓存 最 大 数 的 功能 ， 效 率 不 如 前 者 高 。 使 用 的 最 多 的 获取 缓存 是 从 前 者 获取 的 ， 而 添加 缓存 会 给 两 者 同时 添加 ， 
的 缓存 的 同时 也 删除 前 者 对 应 的 缓存 。 这 种 将 两 种 Map 的 优点 结合 起 来 的 用 法 非常 值得 我 们 学 习 和 借鉴 。 


持 并 发 访问 ， 效 
后 者 如 果 发 现 缓存 数量 已 达到 上 限时 会 在 删除 自己 最 前 面 


UrlBasedViewResolver 


UrlBasedViewResolver 里 面 重 写 了 父 类 | 


的 getCacheKey、createView 和 IloadView 三 个 方法 。 


getCacheKey 方 法 直接 返回 viewName， 它 用 于 父 类 AbstractCachingViewResolver 中 设置 缓存 的 key， 原 来 (AbstractCachingViewResolver 中 ) 使 
UrlBasedViewResolver 的 缓存 中 Key 没有 使 用 Locale 只 使 用 了 viewName， 从 这 里 可 以 看 出 UrlBasedViewResolver 不 支持 Locale。 


的 是 viewName+ “”+locale， 也 就 是 说 


在 createView 中 首先 检查 是 否 可 以 解析 传 入 的 逻辑 视图 ， 如 果 不 可 以 则 返 
以 “redirect: ”或 “forward: ”开头 ， 如 果 是 则 返 


回 


nulliF 别 的 ViewResolver 解 析 ， 接 着 分 别 检查 是 不 是 redirect 视 图 或 者 forward 视 图 ， 检 查 的 方法 是 看 是 不 是 
相应 视图 ， 如 果 都 不 是 则 交 给 父 类 的 createView， 父 类 中 又 调用 了 loadView， 代 码 如 下 : 


回 


//org.springframework.web.servlet .view.UrlBasedViewResolver 
protected View createView (String viewName, Locale locale) throws Exception { 
// 检查 是 否 支持 此 逻辑 视图 ， 可 以 配置 支持 的 模板 
if (!canHandle (viewName, locale)) { 
return null; 


E 

// 检查 是 不 是 redirect 视 图 

if (viewName.startsWith (REDIRECT URL PREFIX)) { 
String redirectUr1 = viewName.substring (REDIRECT URL PREFIX.length()); 
RedirectView view = new RedirectView (redirectUrl, isRedirectContextRelative(), isRedirectHttpl0OCompatible()); 
return applyLifecycleMethods (viewName, view); 

} 

// 检查 是 不 是 forward 视 图 

if (viewName.startsWith (FORWARD URL PREFIX)) { 


String forwardUrl = viewName.substring (FORWARD URL PREFIX.length()); 
return new InternalResourceView (forwardUr1); 


} 
// 如 果 都 不 是 则 调用 父 类 的 createView， 也 就 会 调用 loadView 
return super.createView (viewName, locale); 


其 实 这 里 是 为 所 有 UrlBasedViewResolver 子 类 解析 器 统一 添加 了 检查 是 否 支持 传 入 的 逻辑 视图 和 传 入 的 逻辑 视 
是 通过 可 以 配置 的 viewNames 属 性 检查 的 ， 如 果 没 有 配置 则 可 以 解析 所 有 逻辑 视 
满足 的 模板 ， 如 “*report” “goto*”“*from*” 等 ， 代 码 如 下 : 


到 是 不 是 redirect 或 者 forward 视 图 的 功能 。 检 查 是 否 支持 是 调用 的 canHandle 方 法 , 它 
， 如 果 配 置 了 则 按 配置 的 模式 检查 ， 配 置 的 方法 可 以 直接 将 所 有 可 以 解析 的 逻辑 视图 配置 进去 ， 也 可 以 配置 逻辑 视图 需 


FD 六 


[ 


//org.springframework.web.servlet .view.UrlBasedViewResolver 
protected boolean canHandle (String viewName, Locale locale) { 
String[] viewNames = getViewNames (); 


return (ViewNames 一 null || PatternMatchUtils.simpleMatch (viewNames, viewName)); 


loadView 方 法 代码 如 下 : 


//org.springframework.web.servlet .view.UrlBasedViewResolver 

protected View loadView (String viewName, Locale locale) throws Exception { 
AbstractUrlBasedView view = buildView (viewName); 
View result = applyLifecycleMethods (viewName, view); 
return (view.checkResource(locale) ? result : null); 


loadView 一 共 执行 了 三 名 代码 : @ 使 用 buildView 方 法 创建 View; @ 使 用 applyLifecycle-Methods 方 法 对 创建 的 View 初 始 化 ; @@ 检 查 view 对 应 的 模板 是 否 存 在 ， 如 果 存 在 则 将 初始 化 的 视图 返回 ， 否 
则 返回 null 交 给 下 一 个 ViewResolver 处 理 。 


[ 


applyLifecycleMethods 方 法 是 通过 容器 获取 到 Factory 然 后 实现 的 。 


//org.springframework.web.servlet .view.UrlBasedViewResolver 
private View applyLifecycleMethods (String viewName, AbstractView view) { 
return (View) getApplicationContext () .getAutowireCapableBeanFactory() .initializeBean (view, viewName); 


} 


下 面 来 看 一 下 buildView 方 法 ， 它 用 于 具体 创建 View， 理 解 了 这 个 方法 就 知道 Abstract-UrlBasedView 系 列 中 View 是 怎么 创建 的 了 ， 它 的 子 类 只 是 在 这 里 创建 出 来 的 视图 的 基础 上 设置 了 一 些 属性 。 所 
以 这 是 AbstractUrlBasedView 中 最 重要 的 方法 ， 代 码 如 下 : 


Man 


//org.springframework.web.servlet .view.UrlBasedViewResolver 
protected AbstractUrlBasedView buildView (String viewName) throws Exception { 
AbstractUrlBasedView view = (AbstractUrlBasedView) BeanUtils.instantiateClass (getViewClass()); 
view. setUr] (getPrefix() + viewName + getSuffix()); 
// 如 果 contentType 不 为 hull1， 将 其 值 设置 给 view， 可 以 在 ViewResolver 中 配置 
String contentType = getContentType () 7 
if (contentType != null) { 
View.setContentType (contentType); 
} 
View.setRequestContextAttribute (getRequestContextAttribute()); 
View.setAttributesMap (getAttributesMap () ) 7 
// 如 果 exposePathVariables 不 为 na11， 将 其 值 设置 给 view， 它 用 于 标示 是 否 让 view 
使 用 PathVariables， 可 以 在 ViewResolver 中 配置 。PathVariables 就 是 处 理 器 中 
PathVariables 注 释 的 参数 
Boolean exposePathVariables = getExposePathVariables () 
if (exposePathVariables != null) { 
View.setExposePathVariables (exposePathVariables) 
// 如 果 exposeContextBeansAsAttributes 不 为 nul1l1， 将 其 值 设 置 给 view， 它 用 于 标示 是 否 可 以 
// 让 view 使 用 容器 中 注册 的 bean， 此 参数 可 以 在 ViewResolver 中 配置 
Boolean exposeContextBeansAsAttributes = getExposeContextBeansAsAttributes (); 
if (exposeContextBeansAsAttributes != null) { 
View.setExposeContextBeansAsAttributes (exposeContextBeansAsAttributes); 


} 
// 如 果 exposedContextBeanNames 不 为 hull1， 将 其 值 设 置 给 view， 它 用 于 配置 view 可 以 使 用 容器 
// 中 的 哪些 bean， 可 以 在 ViewResolver 中 配置 
String[] exposedContextBeanNames = getExposedContextBeanNames (); 
if (exposedContextBeanNames != null) { 
View.setExposedContextBeanNames (exposedContextBeanNames); 
} 


return view; 


View 的 创建 过 程 也 非常 简单 ， 首 先 根据 使 用 BeanUtils 根 据 getViewClass 方 法 的 返回 值 创建 出 view， 然 后 将 viewName 加 上 前 级 、 后 缀 设置 为 url， 前 缀 和 后缀 可 以 在 配置 ViewResolver 时 进行 设置 ， 这 
样 View 就 创建 完了 ， 接 下 来 根据 配置 给 View 设 置 一 些 参数 ， 具 体内 容 已 经 注释 到 代码 上 了 。 这 里 的 getViewClass 返 回 其 中 的 viewClass 属 性 ， 代 表 View 的 视图 类 型 ， 可 以 在 子 类 通过 setViewClass 方 法 进 
行 设置 。 另 外 还 有 一 个 requiredViewClass 方 法 ， 它 用 于 在 设置 视图 时 判断 所 设置 的 类 型 是 否 支持 ， 在 UrlBasedViewResolver 中 默认 返回 AbstractUrlBasedView 类 型 ，requiredViewClass 使 用 在 设置 视图 
的 setViewClass 方 法 中 ， 代 码 如 下 : 


//org.springframework.web.servlet .view.UrlBasedViewResolver 
public void setViewClass (Class<?> viewClass) { 


if (viewClass == null || !requiredViewClass() .isAssignableFrom(viewClass)) { 
throw new IllegalArgumentException( 
"Given view class [" + (viewClass != null ? viewClass.getName() : null) + 
"] is not of type [" + requiredViewClass() .getName () + "]"); 


i 
this.viewClass = viewClass; 

} 

protected Class<?> requiredViewClass() { 
return AbstractUrlBasedView.class; 


} 


UrlBasedViewResolver 的 代码 就 分 析 完 了 ， 通 过 前 面 的 分 析 可 知 ， 只 需要 给 它 设置 Abstract-UrlBasedView 类 型 的 viewClass 就 可 以 直接 使 用 了 ， 我 们 可 以 直接 注册 配置 了 viewClass 的 
UrlBasedViewResolver 来 使 用 ， 不 过 最 好 还 是 使 用 相应 的 子 类 。 


UrlBasedViewResolver 的 子 类 主要 做 三 件 事 : @@ 通 过 重 写 requiredViewClass 方 法 修改 了 必须 符合 的 视图 类 型 的 值 ; @ 使 用 setViewClass 方 法 设置 了 所 用 的 视图 类 型 ; @ 给 创建 出 来 的 视图 设置 一 些 属 
性 。 下 面 来 看 一 下 使 用 得 非常 多 的 InternalResourceViewResolver 和 FreeMarkerViewResolver， 前 者 用 于 解析 jsp 视 图 后 者 用 于 解析 FreeMarker 视 图 ， 其 他 实现 类 也 都 差不多 。 


InternalResourceViewResolver 直 接 继承 自 UrlBasedViewResolver， 它 在 构造 方法 中 设置 了 viewClass， 在 buildView 中 对 父 类 创建 的 View 设 置 了 一 些 属性 ，requiredViewClass 方 法 返回 
InternalResourceView 类 型 ， 代 码 如 下 : 


//org.sPringframework.web.servlet.view.InternalResourceViewResolVer 
Public InternalResourceViewResolver () { 
Class<?> ViewClass = requiredViewClass () 
if (viewClass.equals (InternalResourceView.class) && jstlPresent) { 
ViewClass = JstlView.class; 
} 
setViewClass (viewClass); 
} 
protected Class<?> requiredViewClass() { 
return InternalResourceView.class; 
} 
protected AbstractUrlBasedView buildView (String viewName) throws Exception { 
InternalResourceView view = (InternalResourceView) super.buildView (viewName); 
if (this.alwaysInclude != null) { 
View.setAlwaysInclude (this.alwaysInclude); 
} 
View.setPreventDispatchLoop (true); 
return view; 


buildView 方 法 中 给 创建 出 来 的 View 设 置 的 alwayslnclude 用 于 标示 是 否 在 可 以 使 用 forward 的 情况 下 也 强制 使 用 include， 默 认为 false， 可 以 在 注册 解析 器 时 配置 。setPreventDispatch- 
Loop (true) 用 于 阻止 循环 调用 ， 也 就 是 请 求 处 理 完成 后 又 转发 回 了 原来 使 用 的 处 理 器 的 情况 。 


FreeMarkerViewResolver 继 承 自 UrlBasedViewResolver 的 子 类 AbstractTemplateViewResol-ver，AbstractTemplateViewResolver 是 所 用 模板 类 型 ViewResolver 的 父 类 ， 它 里 面 主要 对 创建 的 View 
设置 了 一 些 属性 ， 并 将 requiredViewClass 的 返回 值 设置 为 AbstractTemplateView 类 型 。 代 码 如 下 : 


//org.springframework.web.servlet .view.AbstractTemplateViewResolver 


protected Class<?> 


requiredViewClass() { 


return AbstractTemplateView.class; 


protected AbstractUrlBasedView buildView (String viewName) throws Exception { 
AbstractTemplateView view = (AbstractTemplateView) super.buildView (viewName); 
View.setExposeRequestAttributes (this.exposeRequestAttributes); 
View.setAllowRequestOverride (this.allowRequestOverride); 
View.setExposeSessionAttributes (this.exposeSessionAttributes); 
view.setAllowSessionOverride (this.allowSessionOverride); 


View. setExpose. 
return view; 


SpringMacroHelpers (this .exposeSpringMacroHelpers); 


下 面 解释 这 5 个 属性 的 含义 : 


“ exposeRequestAttributes: 是 否 将 所 有 RequestAttributes 暴 露 给 view 使 用 ， 默 认为 false。 


' allowRequestOverride: 当 RequestAttributes 中 存在 Model 中 同名 的 参数 时 ， 是 否 允 许 使 用 RequestAtttibutes 中 的 值 将 Model 中 的 值 覆 盖 ， 默 认为 fse。 


， exposeSessionAttributes; 是 否 将 所 有 SessionAttributes 暴 露 给 view 使 用 ， 默 认为 false。 


“ allowSessionOverride: 当 SessionAtttibutes 中 存在 Model 中 同名 的 参数 时 ， 是 否 允 许 使 用 RequestAttributes 中 的 值 将 Model 中 的 值 覆 盖 ， 默 认为 false。 


exposeSpringMacroHelpers: 是 否 将 RequestContext 暴 露 给 view 为 spring 的 宏 使 用 ， 上 默认 为 true。 


FreeMarkerViewResolver 的 代码 就 非常 简 生 


package org.spring 


framework.web.servlet .view.freemarker; 


import org.springframework.web.servlet .view.AbstractTemplateViewResolver; 
public class FreeMarkerViewResolver extends AbstractTemplateViewResolver { 
public FreeMarkerViewResolver() { 


setViewCla: 


} 
protected Clas: 


ss (requiredViewClass ()); 


s<?> requiredViewClass() { 


return FreeMarkerView.class; 


} 


UrlBasedViewResolver 就 分 析 完 了 ， 它 实际 完成 了 根据 子 类 提供 的 viewClass 类 型 创建 视图 的 功能 ， 它 的 子 类 只 需要 提供 viewClass 就 可 以 了 ， 有 的 子 类 会 在 创建 完 的 视 | 


14.3 :小 千 


了 ， 只 是 覆盖 requiredViewClass 方 法 返回 FreeMarkerView 类 型 ， 并 在 构造 方法 中 调用 setViewClass 方 法 设置 了 viewClass。 


上 设置 一 些 属 性 。 


[ 


本 章 详细 分 析 了 Spring MVC 中 ViewResolver 的 各 种 实现 方式 。 大 部 分 实现 类 都 继承 自 AbstractCachingViewResolver， 它 提供 了 对 解析 结果 进行 缓存 的 统一 解决 方案 ， 它 的 子 类 中 
ResourceBundleViewResolver 和 XmlViewResolver 分 别 通过 properties 和 xml 配 置 文 件 进 行 解析 ，UrlBasedViewResolver 将 viewName 添 加 前 后 绎 后 用 作 url， 它 的 子 类 只 需要 提供 视图 类 型 就 可 以 了 。 


除了 AbstractCachingViewResolver 外 ， 还 有 三 个 类 : BeanNameViewResolver、Content-Negotiating-ViewResolver 和 ViewResolverComposite。 第 一 个 通过 在 spring 容 器 里 使 用 viewName 查 找 


bean 来 作为 View; 第 二 个 是 使 用 内 部 封装 的 ViewResolver 解 析 后 再 根据 MediaType 或 后 缀 找 出 最 优 的 视图 ; 第 三 个 是 直接 遍历 内 部 封装 的 ViewResolver 进 行 解析 。 这 三 个 类 中 第 一 个 的 视图 是 在 spring 容 


[ 


器 中 ， 后 两 个 是 通过 别 的 ViewResolver 进 行 解 析 的 ， 都 不 需要 直接 创建 View， 所 以 也 不 需要 缓存 。 


解析 视图 的 核心 工作 就 是 查找 模板 文件 和 视图 类 型 ， 而 查找 的 主要 参数 只 有 viewName 一 个 (Locale 只 能 起 辅助 作 


) 。 


这 就 产生 了 三 种 解析 思路 : @ 使 用 viewName 查 找 模板 文件 ，@ 使 


viewName 查 找 视图 类 型 ;@ 使 用 viewName 同 时 查找 模板 文件 和 视图 类 型 。Spring MVC 对 这 三 种 思路 都 提供 了 实现 的 方式 ， 第 一 种 思路 对 应 的 是 UrlBasedViewResolver 系 列 ;第 二 种 思路 对 应 的 是 


BeanNameViewResolver; 第 三 种 思路 对 应 的 是 ResourceBundleViewResolver 和 XmlViewResolver。 理 解 了 这 
ResourceBundleViewResolver 和 Xml-ViewResolver 再 提取 一 个 父 类 出 来 就 更 清晰 了 。 另 外 需要 注意 的 是 ， 并 不 是 每 个 请 求 都 需要 使 用 ViewResolver， 只 有 当 处 理 器 执行 后 view 是 String 类 型 时 才 需 


来 解析 。 


第 15 章 Requ 


RequestToViewNameTranslator 可 以 在 处 理 器 返 


层 意思 就 能 明白 


Spring MVC 中 ViewResolver 的 结构 为 什么 这 么 安排 了 ， 如 果 


Q 


estToViewNameTranslator 


回 


简单 ， 只 是 因为 有 一 些 getter/setter 方 法 ， 所 以 看 起 来 代码 比较 多 ， 实 际 执行 解析 的 只 有 两 个 ， 代 码 如 下 : 


的 view 为 空 时 使 用 它 根 据 request 获 取 viewName。Spring MVC 提 供 的 实现 类 只 有 一 个 DefaultRequestToViewNameTranslator， 这 个 类 也 非常 


//org.springframework.web.servlet .view.DefaultRequestToViewNameTranslator 


public String getV: 


iewName (HttpServletRequest request) { 


String lookupPath = this.urlPathHelper.getLookupPathForRequest (request); 
return (this.prefix + transformPath (lookupPath) + this.suffix); 


} 


protected String transformPath (String lookupPath) { 


String path = 


lookupPath; 


if (this.stripLeadingSlash && path.startsWith (SLASH)) { 
Path = path.substring (1); 


i 


if (this.stripTrailingSlash && path.endsWith (SLASH)) { 
path = path.substring(0, path.length() - 1); 


} 


if (this.stripExtension) { 


Path = Str: 
} 
if (!SLASH.equa. 


ingUtils.stripFilenameExtension (path); 


ls(this.separator)) { 


path = StringUtils.replace (path, SLASH, this.separator); 


} 


return path; 


getViewName 是 接 


口 定义 的 方法 ， 实 际 解析 时 就 调用 它 。 在 getViewName 中 首先 从 request 获 得 lookupPath， 然 


后 使 


transformpPath 方 法 对 其 进行 处 理 后 加 上 前 缀 后 缀 返回 。transformPath 方 法 


的 作用 简单 来 说 就 是 根据 配置 对 lookupPath “的 头 去 尾 换 分 隔 符 ” ， 它 是 根据 其 中 的 四 个 属性 的 设置 来 处 理 的 ， 下 面 分 别 解 释 一 下 这 四 个 属性 ， 其 中 用 到 的 Slash 是 一 个 静态 常量 ， 表示“/”。 


* sttripLeadingSlash: 


如 果 最 前 面 的 字符 为 Slash 是 否 将 其 去 掉 。 


“ stripTrailingSlash: 如 果 最 后 一 个 字符 为 Slash 是 否 将 其 去 掉 。 


' sttipExtension: 是 


否 需要 去 掉 扩展 名 。 


“ separator: 如 果 其 值 与 Slash 不 同 则 用 于 替换 原来 的 分 隔 符 Slash。 


getViewName 中 还 使 用 了 可 以 给 返回 值 添 力 。 可 以 配置 的 参数 除了 这 6 个 外 还 有 4 个 : urlDecode、removeSemicolonContent、 
alwaysUseFullPath 和 urlPathHelper， 前 三 个 参 : 


数 都 是 用 在 urlPathHelper 中 的 ，urlDecode 用 于 设置 url 是 否 需要 编 和 解码， 一 般 默 认 就 行 ，removeSemicolonContent 在 前 面 已 经 说 过 了 ， 
除 url 中 与 分 号 相关 的 内 容 ; alwaysUseFullPath 用 于 设置 是 否 总 使 用 完整 路 径 ; urlPathHelper 是 用 于 处 理 ur| 的 工具 ， 一 般 使 


[0 前缀 和 后 缀 的 prefix 和 suffix， 这 些 参数 都 可 以 配 


spring 默 认 提 供 的 就 可 以 了 。 
RequestToViewNameTranslator 组 件 非常 简单 ， 本 章 就 介绍 到 这 里 。 
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HandlerExceptionResolver 用 于 解析 请 求 处 理 过 程 中 所 产生 的 异常 ， 继 承 结构 如 


图 16-1 所 示 。 


4 9 HandlerExceptionResolver| 
4 O° AbstractHandlerExceptionResolver 
4 © AbstractHandlerMethodExceptionResolver 
© ExceptionHandlerExceptionResolver 


AnnotationMethodHandlerExceptionResolver 
DefaultHandlerExceptionResolver 
ResponseStatusExceptionResolver 


SimpleMappingExceptionResolver 
OG HandlerExceptionResolverComposite 


图 16-1 HandlerExceptionResolver 继 承 结构 图 


其 中 HandlerExceptionResolverComposite 作 为 容器 使 用 ， 可 以 封装 别 的 Resolver， 前 面 已 经 多 次 介绍 过 ， 这 里 就 不 再 叙述 了 。 


HandlerExceptionResolver 的 主要 实现 都 继承 自 抽象 类 AbstractHandlerExceptionResolver， 它 有 五 个 子 类 ， 其 中 的 AnnotationMethodHandlerExceptionResolver 已 经 被 弃 用 


， 剩 下 的 还 有 四 个 : 
' AbstractHandlerMethodExceptionResolver: 和 其 子 类 ExceptionHandlerExceptionResolvet 一 起 完成 使 用 @ExceptionHandler 注 释 的 方法 进行 异常 解析 的 功能 。 
“ DefaultHandlerExceptionResolver: 按 不 同类 型 分 别 对 异常 进行 解析 。 


“ ResponseStatusExceptionResolver: 解析 有 (@ResponseStatus 注 释 类 型 的 异常 。 


“ SimpleMappingExceptionResolver: 通过 配置 的 异常 类 和 view 的 对 应 关系 来 解析 异常 。 


异常 解析 过 程 主要 包含 两 部 分 内 容 : 给 ModelAndView 设 置 相应 内 容 、 设 置 response 的 相关 属性 。 当 然 还 可 能 有 一 些 辅助 功能 ， 如 记录 日 志 等 ， 在 自 定义 的 ExceptionHandler 里 还 可 以 做 更 多 的 事 
情 。 
16.1 


AbstractHandlerExceptionResolver 


AbstractHandlerExceptionResolver 是 所 有 直接 解析 异常 类 的 父 类 ， 里 面 定义 了 通 


的 解析 流程 ， 并 使 


了 模板 模式 ， 子 类 只 需要 履 盖 相应 的 方法 即 可 ，resolveException 方 法 如 下 : 


// org.springframework.web.servlet.handler.AbstractHandlerExceptionResolver 


Public ModelAndView resolveException (HttpServletRequest request, HttpServletResponse response, 
Object handler, Exception ex) { 


if (shouldApplyTo (request, handler)) { 
if (logger.isDebugEnabled()) { 


logger .debug ("Resolving exception from handler[" 
} 


"+ handler + "]: "+ ex)? 
logException (ex, request); 


PrepareResponse (ex, response); 

return doResolveException (request, response, handler, ex); 
} else { 

return null; 


} 


首先 使 用 shouldApplyTo 方 法 判断 当前 ExceptionResolver 是 否 可 以 解析 所 传 入 处 理 器 所 抛 出 的 异常 (可 以 指定 只 能 处 理 指定 的 处 理 器 抛 出 的 异常 ) ， 如 果 不 可 以 则 返回 
ExceptionResolver 解 析 ， 如 果 可 以 则 调用 logException 方 法 打印 日 志 ， 接 着 调 


给 子 类 实现 。 


null， 交 给 下 一 个 
doResolveException 实 际 解析 异常 ，doResolveException 是 个 模板 方法 ， 留 


prepareResponse 设 置 response， 最 后 调 


shouldApplyTo 方 法 的 代码 如 下 : 


// org.springframework.web.servlet.handler.AbstractHandlerExceptionResolver 
protected boolean shouldApplyTo (HttpServletRequest request, Object handler) { 
if (handler != null) { 
if (this.mappedHandlers != null && this.mappedHandlers.contains (handler)) { 
return true; 
} 
if (this.mappedHandlerClasses != null) { 
for (Class<?> handlerClass : this.mappedHandlerClasses) { 
if (handlerClass.isInstance (handler)) { 
return true; 


} 


} 
} 
return (this.mappedHandlers 一 null && this.mappedHandlerClasses 一 null); 


这 里 使 用 了 两 个 属性 : mappedHandlers 和 mappedHandlerClasses， 这 两 个 属性 可 以 在 定义 HandlerExceptionResolver 的 时 候 进行 配置 ， 用 于 指定 可 以 解析 处 理 器 抛 出 的 哪些 异常 ， 也 就 是 如 果 设 置 
了 这 两 个 值 中 的 一 个 ， 那 么 这 个 ExceptionResolver 就 只 能 解析 所 设置 的 处 理 器 抛 出 的 异常 。mappedHandlers 用 于 配置 处 理 器 的 集合 ，mappedHandlerClasses 用 于 配置 处 理 器 类 型 的 集合 。 检 查 方法 非 
常 简 单 ， 在 此 就 不 细 说 了 ， 如 果 两 个 属性 都 没 配置 则 将 处 理 所 有 异常 。 


logException 是 默认 记录 日 志 的 方法 ， 代 码 如 下 : 


// org.springframework.web.servlet.handler.AbstractHandlerExceptionResolver 
protected void logException (Exception ex, HttpServletRequest request) { 
if (this.warnLogger != null && this.warnLogger.isWarnEnabled()) { 
this.warnLogger .warn (buildLogMessage (ex, request), ex); 
} 
} 
protected String buildLogMessage (Exception ex, HttpServletRequest request) { 
return "Handler execution resulted in exception"; 


} 


logException 方 法 首先 调用 buildLogMessage 创 建 了 日 志 消 息 ， 然 后 使 用 warnLogger 将 其 记录 下 来 。 


prepareResponse 方 法 根据 preventResponseCaching 标 示 判 断 是 否 给 response 设 置 禁用 缓存 的 属性 ，preventResponseCaching 默 认为 false， 代 码 如 下 : 


// org.springframework.web.servlet.handler.AbstractHandlerExceptionResolver 
protected void prepareResponse (Exception ex, HttpServletResponse response) { 
if (this.preventResponseCaching) { 
PreventCaching (response); 
} 
} 
protected void preventCaching (HttpServletResponse response) { 
response. setHeader (HEADER PRAGMA, "no-cache"); 
response. setDateHeader (HEADER FXPIRES, 1L); 
response. setHeader (HEADER CACHE CONTROL, "no-cache"); 
response.addHeader (HEADER CACHF CONTROL, "no-store"); 


最 后 的 doResolveException 方 法 是 模板 方法 ， 子 类 使 用 它 具 体 完成 异常 的 解析 工作 


16.2 ”ExceptionHandlerExceptionResolver 


ExceptionHandlerExceptionResolver 继 承 


AbstractHandlerMethodExceptionResolver， 后 者 继承 自 AbstractHandlerExceptionResolver。AbstractHandlerMethodExceptionResolve 
shouldApplyTo 方 法 ， 并 在 处 理 请 求 的 doResolveException 方 法 中 将 实际 处 理 请 求 的 过 程 交 给 了 模板 方法 doResolveHandlerMethodException。 代 码 如 下 : 


Package org.springframework.web.servlet.handler; 
// 省 略 了 imports 
public abstract class AbstractHandlerMethodExceptionResolver extends AbstractHandlerExceptionResolver { 
QOverride 
protected boolean shouldApplyTo (HttpServletRequest request, Object handler) { 
if (handler == null) { 
return super.shouldApplyTo (request, handler); 
} else if (handler instanceof HandlerMethod) { 
HandlerMethod handlerMethod = (HandlerMethod) handler; 
handler = handlerMethod.getBean (); 
return super.shouldApplyTo (request, handler); 
} else { 
return false; 
} 
} 
QOverride 
protected final ModelAndView doResolveException( 
HttpServletRequest request, HttpServletResponse response, 
Object handler, Exception ex) { 
return doResolveHandlerMethodException (request, response, (HandlerMethod) handler, ex); 
} 
protected abstract ModelAndView doResolveHandlerMethodException( 
HttpServletRequest request, HttpServletResponse response, 
HandlerMethod handlerMethod, Exception ex); 


AbstractHandlerMethodExceptionResolver 的 作用 其 实 相当 于 一 个 适配器 。 一 般 的 处 理 器 是 类 的 形式 ， 但 HandlerMethod 其 实 是 将 方法 作为 处 理 器 来 使 用 的 ， 所 以 需要 进行 适 配 。 首 先 在 
shouldApplyTo 中 判断 如 果 处 理 器 是 HandlerMethod 类 型 则 将 处 理 器 设置 为 其 所 在 的 类 ， 然 后 再 交 给 父 类 判断 ， 如 果 为 空 则 直接 交 给 父 类 判断 ， 如 果 既 不 为 空 也 不 是 HandlerMethod 类 型 则 返回 false 不 处 
理 。 


doResolveException 将 处 理 传递 给 doResolveHandlerMethodException 方 法 具体 处 理 ， 这 样 做 主要 是 为 了 层次 更 加 合理 ， 而 且 这 样 设计 后 如 果 有 多 个 子 类 还 可 以 在 doResolveException 中 统一 做 一 
些 事情 。 


下 面 来 看 ExceptionHandlerExceptionResolver， 它 其 实 就 是 一 个 简化 版 的 RequestMapping-HandlerAdapter， 它 的 执行 也 是 使 用 的 ServletiInvocableHandlerMethod， 首 先 根据 handlerMethod 
和 exception 将 其 创建 出 来 (大 致 过 程 是 在 处 理 器 类 里 找 出 所 有 注释 了 @Exception-Handler 的 方法 ， 然 后 再 根据 其 配置 中 的 异常 和 需要 解析 的 异常 进行 匹配 ) ， 然 后 设置 了 argumentResolvers 和 
returnValueHandlers， 接 着 调用 其 invokeAndHandle 方 法 执行 处 理 ， 最 后 将 处 理 结果 封装 成 ModelAndView 返 回 。 如 果 RequestMappingHandlerAdapter 理 解 了 ， 再 来 看 它 就 会 觉得 非常 简单 。 代 码 如 
下 


//org.springframework.web.servlet .mvc.method.annotation.FExceptionHandlerExceptionResolver 
protected ModelAndView doResolveHandlerMethodException (HttpServletRequest request, 
HttpServletResponse response, HandlerMethod handlerMethod, Exception exception) { 
// 找到 处 理 异常 的 方法 


ServletInvocableHandlerMethod exceptionHandlerMethod = getExceptionHandlerMethod (handlerMethod, exception); 
if (exceptionHandlerMethod == null) { 
return null; 


// 设置 argumentResolvers 和 returnValueHandlers 
exceptionHandlerMethod. setHandlerMethodArgumentResolvers (this.argumentResolvers); 
exceptionHandlerMethod.setHandlerMethodReturnValueHandlers (this.returnValueHandlers); 
ServletWebRequest webRequest = new ServletWebRequest (request, response); 
ModelAndViewContainer mavContainer = new ModelAndViewContainer (); 
try { 

Y if (logger.isDebugEnabled()) { 

logger.debug ("Invoking QExceptionHandler method: " + exceptionHandlerMethod); 


} 
// 执行 ExceptionHandler 方 法 解析 异常 
exceptionHandlerMethod.invokeAndHandle (webRequest, mavContainer, exception); 
} catch (Exception invocationEx) { 
if (logger.isErrorEnabled()) { 
logger.error ("Failed to invoke @ExceptionHandler method: " + exception-HandlerMethod, invocationEx); 


return null; 
if (mavContainer.isRequestHandled()) { 
return new ModelAndView (); 
} else { 
ModelAndView mav = new ModelAndView () .addAllObjects (mavContainer .getModel ()); 
mav. setViewName (mavContainer .getViewName () ) 7 
if (!mavContainer.isViewReference()) { 
mav.setView( (View) mavContainer.getView()); 
} 


return mav; 


这 里 只 是 返回 了 ModelAndView， 并 没有 对 response 进 行 设置 ， 如 果 需 要 可 以 自己 在 异常 处 理 器 中 设置 。 


16.3 DefaultHandlerExceptionResolver 


DefaultHandlerExceptionResolver 的 解析 过 程 是 根据 异常 类 型 的 不 同 ， 使 用 不 同 的 方法 进行 处 理 ，doResolveException 代 码 如 下 : 


//org.springframework.web.servlet .mvc.support .DefaultHandlerExceptionResolver 
protected ModelAndView doResolveException (HttpServletRequest request, HttpServletResponse response, 
Object handler, Exception ex) { 
try { 
if (ex instanceof NoSuchRequestHandlingMethodException) { 
return handleNoSuchRequestHandlingMethod ( (NoSuchRequestHandlingMethodException) ex, request, response, handler); 
} else if (ex instanceof HttpRequestMethodNotSupportedException) { 
return handleHttpRequestMethodNotSupported ( (HttpRequestMethodNotSupportedException) ex, request, response, handler); 
} else if (ex instanceof HttpMediaTypeNotSupportedException) { 
return handleHttpMediaTypeNotSupported ( (HttpMediaTypeNotSupportedException) ex, request, response, handler); 
} else if (ex instanceof HttpMediaTypeNotAcceptableException) { 
return handleHttpMediaTypeNotAcceptable ( (HttpMediaTypeNotAcceptableException) ex, request, response, handler); 
} else if (ex instanceof MissingServletRequestParameterException) { 
return handleMissingServletRequestParameter ( (MissingServletRequestParameterException) ex, request, response, handler); 
} else if (ex instanceof ServletRequestBindingException) { 
return handleServletRequestBindingException( (ServletRequestBindingException) ex, request, response, handler); 
} else if (ex instanceof ConversionNotSupportedException) { 
return handleConversionNotSupported( (ConversionNotSupportedException) ex, request, response, handler); 
} else if (ex instanceof TypeMismatchException) { 
return handleTypeMismatch ( (TypeMismatchException) ex, request, response, handler); 
} else if (ex instanceof HttpMessageNotReadableException) { 
return handleHttpMessageNotReadable ( (HttpMessageNotReadableFException) ex, request, response, handler); 
} else if (ex instanceof HttpMessageNotWritableException) { 
return handleHttpMessageNotWritable( (HttpMessageNotWritableException) ex, request, response, handler); 
} else if (ex instanceof MethodArgumentNotValidException) { 
return handleMethodArgumentNotValidException ( (MethodArgumentNotValidException) ex, request, response, handler); 
}else if (ex instanceof MissingServletRequestPartException) { 
return handleMissingServletRequestPartException( (MissingServletRequestPartException) ex, request, response, handler); 
}else if (ex instanceof BindException) { 
return handleBindException ( (BindException) ex, request, response, handler); 
}else if (ex instanceof NoHandlerFoundException) { 
return handleNoHandlerFoundException ( (NoHandlerFoundException) ex, request, response, handler); 
} 
}catch (Exception handlerException) { 
logger.warn("Handling of [" + ex.getClass () .getName () + "] resulted in Exception", handlerException); 


return null; 


具体 的 解析 方法 也 非常 简单 ， 主 要 是 设置 response 的 相关 属性 ， 下 | 


回 


介绍 前 两 个 异常 的 处 理 方法 ， 也 就 是 没 找到 处 理 器 执行 方法 和 request 的 Method 类 型 不 支持 的 异常 处 理 ， 代 码 如 下 : 


//org.sPringframework.web.servlet.mvc.support.DefaultHandlerExceptionResolvVer 
protected ModelAndView handleNoSuchRequestHandlingMethod (NoSuchRequestHandlingMethodException ex, 
HttpServletRequest request, HttpServletResponse response, Object handler) throws IOException { 
pageNotFoundLogger .warn (ex.getMessage () ); 
response.sendError (HttpServletResponse.sC_ NOT _ FOUND); 
return new ModelAndView(); 
} 
protected ModelAndView handleHttpRequestMethodNotSupported (HttpRequestMethodNotSupportedException ex, HttpServletRequest request, HttpServletResponse response, Object handler) 
pageNotFoundLogger .warn (ex.getMessage () ) 7 
String[] supportedMethods = ex.getSupportedMethods (); 
if (supportedMethods != null) { 
response.setHeader ("Allow", StringUtils.arrayToDelimitedString (supportedMethods, ", ")); 
[; 
response.sendError (HttpServletResponse.SsC METHOD NOT ALLOWED, ex.getMessage()); 
return new ModelAndView (); 


可 以 看 到 其 处 理 方 法 就 是 给 response 设 置 了 相应 属性 ， 然 后 返回 一 个 空 的 Model-AndView。 其 中 response 的 sendError 方 法 用 于 设置 错误 类 型 ， 它 有 两 个 重 载 方法 sendError (int) 和 
sendError (int，String) ，int 参 数 用 于 设置 404) 500 等 错误 类 型 ，String 类 型 的 参数 用 于 设置 附加 的 错误 信息 ， 可 以 在 页 面 中 获取 到 。sendError 和 setstatus 方 法 的 区 别 是 前 者 会 返回 web.xml 中 定义 的 
相应 错误 页 面 ， 后 者 只 是 设置 了 status 而 不 会 返回 相应 错误 页 面 。 其 他 处 理 方法 也 都 大 同 小 异 ， 就 不 解释 了 。 


回 


回 


16.4 ResponseStatusExceptionResolver 


ResponseStatusExceptionResolver 用 来 解析 注释 了 @ResponseStatus 的 异常 (如 自 定义 的 注释 了 @ResponseStatus 的 异常 ) ， 代 码 如 下 : 


//org.springframework.web.servlet .mvc.annotation.ResponseStatusExceptionResolver 
protected ModelAndView doResolveException (HttpServletRequest request, HttpServletResponse response, 
Object handler, Exception ex) { 
ResponseStatus responseStatus = AnnotationUtils.findAnnotation (ex.getClass (), ResponseStatus.class); 
if (responseStatus != null) { 
try { 


return resolveResponseStatus (responseStatus, request, response, handler, ex); 
}catch (Exception resolveEx) { 
logger.warn ("Handling of @ResponseStatus resulted in Exception", resolveEx); 


} 
return null; 
$ 
protected ModelAndView resolveResponseStatus (ResponseStatus responseStatus, HttpServletRequest request, 
HttpServletResponse response, Object handler, Exception ex) throws Exception { 
int statusCode = responseStatus.value() .value(); 
String reason = responseStatus.reason () 7 
if (this.messageSource != null) { 
reason = this.messageSource.getMessage (reason, null, reason, LocaleContextHolder.getLocale()); 
} 
if (!StringUtils.hasLength(reason)) { 
response.sendError (statusCode); 
jelse { 
response.sendError (statusCode, reason); 
} 
return new ModelAndView(); 


doResolveException 方 法 中 首先 使 用 AnnotationUtils 找 到 ResponseStatus 注 释 ， 然 后 调用 resolveResponseStatus 方 法 进行 解析 ， 后 者 使 用 注释 里 的 value 和 reason 作 为 参数 调用 了 response 的 


sendError 方 法 。 


16.5 SimpleMappingExceptionResolver 


SimpleMappingExceptionResolver 需 要 提前 配置 异常 类 和 view 的 对 应 关系 然后 才能 使 用 ，doResolveException 代 码 如 下 : 


//org.springframework.web.servlet .handler.SimpleMappingExceptionResolver 
protected ModelAndView doResolveException (HttpServletRequest request, HttpServletResponse response, 
Object handler, Exception ex) { 
// 根据 异常 查找 显示 错误 页 面 的 还 辑 视 图 
String viewName = determineViewName (ex, request); 
if (viewName != null) { 
// 检查 是 否 配 置 了 所 找到 的 ViewName 对 应 的 statusCode 
Integer statusCode = determineStatusCode (request, viewName); 
if (statusCode != null) { 
apP1YStatusCodeIfPossible (request, response, statusCode); 


return getModelAndView (viewName, ex, request); 
} else { 
return null; 


} 


这 里 首先 调用 determineViewName 方 法 根据 异常 找到 显示 异常 的 逻辑 视图 ， 然 后 调用 determineStatusCode 方 法 判断 逻辑 视图 是 否 有 对 应 的 statusCode， 如 果 有 则 调用 applyStatus-CodelfPossible 


方法 设置 到 response， 最 后 调用 getModelAndView 将 异常 和 解析 出 的 viewName 封 装 成 ModelAndView 并 返回 。 


查找 视图 的 determineViewName 方 法 如 下 : 


//org.springframework.web.servlet.handler.SimpleMappingExceptionResolver 
protected String determineViewName (Exception ex, HttpServletRequest request) { 
String viewName = null; 
// 如 果 异 常 在 设置 的 excludedExceptions 中 所 包含 则 返回 null 


if (this.excludedExceptions != null) { 
for (Class<?> excludedEx : this.excludedExceptions) { 
if (excludedEx.equals (ex.getClass())) { 


return null; 
} 
} 


} 
// 调用 findMatchingViewName 方 法 实际 查找 
if (this.exceptionMappings != null) { 
ViewName = findMatchingViewName (this.exceptionMappings, ex); 


// 如 果 没 找到 viewName 并 且 配 置 了 defaultErrorView， 则 使 用 defaultErrorView 


if (viewName == null && this.defaultErrorView != null) { 
if (logger.isDebugEnabled()) { 
logger.debug ("Resolving to default view '" + this.defaultErrorView + "' for exception of type ["+ 
ex.getClass () .getName () + "]"); 


} 
ViewName = this.defaultErrorView; 


return viewName; 


这 里 首先 检查 异常 是 不 是 配置 在 excludedExceptions 中 (excludedExceptionsf 


于 配置 不 处 理 的 异常 ) ， 如 果 是 则 返回 null， 否 则 调用 findMatchingViewName 实 际 查 找 viewName， 如 果 没 找到 而 


且 配 置 了 defaultErrorView， 则 使 用 defaultErrorView。findMatchingViewName 从 传 入 的 参数 就 可 以 看 出 来 它 是 根据 配置 的 exceptionMappings 参 数 匹 配 当前 异常 的 ， 不 过 并 不 是 直接 完全 
是 只 要 配置 异常 的 字符 在 当前 处 理 的 异常 或 其 父 类 中 存在 就 可 以 了 ， 如 配置 “BindingException” 可 以 匹配 “xxx.UserBindingException” “xxx.DeptBindingException” 等 ， 
而 “java.lang.Exception” 可 以 匹配 所 有 它 的 子 类 ， 即 所 有 “CheckedExceptions”， 其 代码 如 下 : 


匹配 的 ,而 


//org.springframework.web.servlet .handler.SimpleMappingExceptionResolver 
protected String findMatchingViewName (Properties exceptionMappings, FException ex) { 
String viewName = null; 
String dominantMapping = null; 
int deepest = Integer.MAX VALUE; 
for (Enumeration<?> names = exceptionMappings.propertyNames(); names.hasMoreFlements();) { 
String exceptionMapping = (String) names.nextElement (); 
int depth = getDepth (exceptionMapping, ex); 
if (depth >= 0 && (depth < deepest || (depth == deepest && 
dominantMapping != null && exceptionMapping.length() > dominantMapping.length()))) { 
deepest = depth; 
dominantMapping = exceptionMapping; 
ViewName = exceptionMappings.getProperty (exceptionMapping); 
} 
} 
if (viewName != null && logger.isDebugEnabled()) { 


logger.debug ("Resolving to view '" + viewName + "' for exception of type [" + ex.getClass () .getName () +"], based on exception mapping [" + dominantMapping + 


return viewName; 


]); 


大 致 过 程 就 是 遍历 配置 文件 ， 然 后 调用 getDepth 查 找 ， 如 果 返 回 值 大 于 等 于 0 则 说 明 可 以 匹配 ， 而 且 如 果 有 多 个 匹配 项 则 选择 最 优 的 ， 选 择 方法 是 判断 两 项 内 容 : @ 匹 配 的 深度 ;@ 匹 配 的 配置 项 文本 


的 长 度 。 深 度 越 浅 越 好 ， 配 置 的 文本 越 长 越 好 。 深 度 是 指 如 果 匹 配 的 是 异常 的 父 类 而 不 是 异常 本 身 ， 那 么 深度 就 是 异常 本 身 到 被 匹配 的 父 类 之 间 的 继承 层 数 。getDepth 方 法 的 代码 如 下 : 


//org.sPringframework.web.servlet.handler.SimpleMappingExceptionResolver 
protected int getDepth (String exceptionMapping, Exception ex) { 

return getDepth (exceptionMapping, ex.getClass(), 0); 
} 


private int getDepth (String exceptionMapping, Class<?> exceptionClass, int depth) { 
// 如 果 异 常 的 类 名 里 包含 查找 的 配置 文本 则 匹配 成 功 
if (exceptionClass.getName() .contains (exceptionMapping)) { 
return depth; 


} 
// 查找 到 异常 的 根 类 Throwable 还 没 匹 配 ， 则 说 明 不 匹配 ， 返 回 -1 
if (exceptionClass.equals (Throwable.class)) { 
return -1; 
} 
return getDepth (exceptionMapping, exceptionClass.getSuperclass(), depth + 1); 


getDepth 中 调用 了 同名 的 带 depth 参 数 的 递归 方法 getDepth， 并 给 depth 传 入 了 0。 后 面 的 getDepth 方 法 判断 传 入 的 类 名 中 是 否 包含 匹配 的 字符 串 ， 如 果 找 到 则 返回 相应 的 depth， 如 果 没 有 则 对 
depth 加 1 后 递归 检查 异常 的 父 类 ， 直 到 检查 的 类 变 成 Throwable 还 不 匹配 则 返回 -1。 


回 


分 析 完 determineViewName， 再 回 过 头 去 分 析 determineStatusCode， 代 码 如 下 : 


//org.springframework.web.servlet .handler.SimpleMappingExceptionResolver 
protected Integer determineStatusCode (HttpServletRequest request, String viewName) { 
if (this.statusCodes.containsKey (viewName)) { 
return this.statusCodes.get (viewName); 
} 
return this.defaultStatusCode; 


I 


determineStatusCode 方 法 非常 简单 ， 就 是 直接 从 配置 的 statusCodes 中 用 viewName 获 取 ， 如 果 获 取 不 到 则 返回 默认 值 defaultStatusCode，statusCodes 和 defaultStatusCode 都 可 以 在 定义 
SimpleMappingExceptionResolver 的 时 候 进行 配置 。 找 到 statusCode 后 会 调用 applyStatus-CodelfPossible 方 法 将 其 设置 到 response 上 ， 代 码 如 下 : 


//org.spPringframework.web.servlet.handler.SimpleMappingExceptionResolveT 
Protected void applyStatusCodeIlfPossible (HttpServletRequest request, HttpServletResponse response, int statusCode) { 
if (!WebUtils.isIncludeRequest (request)) { 
if (logger.isDebugEnabled()) { 
logger.debug ("Applying HTTP status code " + statusCode); 
} 
response.setStatus (statusCode); 
request.setAttribute (WebUtils.ERROR STATUS CODE ATTRIBUTE, statusCode); 


最 后 调用 getModelAndView 生 成 ModelAndView 并 返回 ， 生 成 过 程 是 将 解析 出 的 viewName 设 置 为 View， 如 果 exceptionAttribute 不 为 空 则 将 异常 添加 到 Model， 代 码 如 下 : 


//org.springframework.web.servlet .handler.SimpleMappingExceptionResolver 
Protected ModelAndView getModelAndView (String viewName, Exception ex, HttpServletRequest request) { 

return getModelAndView (viewName, ex); 
} 
protected ModelAndView getModelAndView (String viewName, Exception ex) { 

ModelAndView mv = new ModelAndView (viewName); 

if (this.exceptionAttribute != null) { 

if (logger.isDebugEnabled()) { 
logger .debug ("Exposing Exception as model attribute '" + this.exceptionAttribute + "'"); 


} 
mv.addOobject (this.exceptionAttribute, ex); 
} 


return mV7 


SimpleMappingExceptionResolver 就 分 析 完 了 ， 这 里 面 有 不 少 可 配置 的 选项 ， 总 结 如 下 : 
“ exceptionMappings: 用 于 配置 异常 类 (字符 串 类 型 ) 和 viewName 的 对 应 关系 ， 异 常 类 可 以 是 异常 (包含 包 名 的 完整 名 ) 的 一 部 分 ， 还 可 以 是 异常 父 类 的 一 部 分 。 
excludedExceptions: 用 于 配置 不 处 理 的 异常 。 
defaultBrrorView: 用 于 配置 当 无 法 从 exceptionMappings 中 解析 出 视图 时 使 用 的 默认 视图 。 
“ statusCodes: 用 于 配置 解析 出 的 viewName 和 statusCode 对 应 关系 。 
.defaultStatusCode: 用 于 配置 statusCodes 中 没有 配置 相应 的 viewName 时 使 用 的 默认 statusCode。 


“ exceptionAttribute: 用 于 配置 异常 在 Model 中 保存 的 参数 名 ， 默 认为 "exception"， 如 果 为 null， 异 常 将 不 保存 到 Model 中 。 


16.6 小 结 


本 章 详细 分 析 了 Spring MVC 中 异常 解析 组 件 HandlerExceptionResolver 的 所 有 实现 类 。 实 现 类 中 除了 HandlerExceptionResolverComposite， 每 个 类 处 理 一 种 异常 处 理 方式 ， 它 们 具体 做 的 工作 主 
包括 将 异常 相关 信息 设置 到 Model 中 和 给 response 设 置 相应 属性 两 个 方面 。 


mvcannotation-driven 会 自动 将 ExceptionHandlerExceptionResolver、DefaultHandlerException-Resolver 和 ResponseStatusExceptionResolver 配 置 到 Spring MVC 
中 ，SimpleMappingException-Resolver 如 果 想 使 用 需要 自己 配置 ， 其 实 SimpleMappingExceptionResolver 的 使 用 还 是 很 方便 的 ， 只 需要 将 异常 类 型 和 错误 页 面 的 对 应 关系 设置 进去 就 可 以 了 ， 而 且 还 可 
以 通过 设置 父 类 将 某 种 类 型 的 所 有 异常 对 应 到 指定 页 面 。 另 外 ExceptionHandlerExceptionResolver 不 仅 可 以 使 用 处 理 器 类 中 注释 的 @ExceptionHandler 方 法 处 理 异常 ， 还 可 以 使 用 @ControllerAdvice 注 
释 的 类 里 有 @ ExceptionHandler 注 释 的 全 局 异常 处 理 方法 。 


一 般 刚 开始 接触 编程 的 人 都 会 对 异常 感到 害怕 ， 也 讨厌 异常 。 不 过 等 学 会 调试 并 随 着 编程 经 验 逐 渐 增多 以 后 慢 慢 会 觉得 异常 还 是 挺 有 用 ， 是 排查 问题 中 非常 有 用 的 武器 。 随 着 自己 慢 慢 成 长 ， 直 到 有 一 
天 自己 也 开始 定义 并 使 用 异常 的 时 候 ， 才 会 发 现 异 常 原来 是 那么 有 用 、 那 么 方便 ! 


HandlerExceptionResolver 是 Spring MVC 提 供 的 非常 方便 的 通用 异常 处 理工 具 ， 不 过 需要 注意 的 是 ， 它 只 能 处 理 请 求 处 理 过 程 中 抛 出 的 异常 ， 异 常 处 理 本 身 所 抛 出 的 异常 和 视图 解析 过 程 中 抛 出 的 异 
常 它 是 不 能 处 理 的 。 


第 17 章 MultipartResolver 


MultipartResolver 用 于 处 理 上 传 请 求 ， 有 两 个 实现 类 : StandardServletMultipartResolver 和 CommonsMultipartResolver。 前 者 使 用 了 Servlet3.0 标 准 的 上 传 方式 ， 后 者 使 用 了 Apache 的 


commons-fileupload。 


17.1 StandardServletMultipartResolver 


StandardServletMultipartResolver 使 用 了 Servlet3.0 标 准 的 上 传 方式 ， 在 Servlet3.0 中 上 传 文件 非常 简单 ， 只 需要 调用 request 的 getParts 方 法 就 可 以 获取 所 有 上 传 的 文件 。 如 果 想 单独 获取 某 个 文件 可 
以 使 用 request.getPart (fileName) ， 获 取 到 Part 后 直接 调用 它 到 write (saveFileName) 方法 就 可 以 将 文件 保存 为 以 saveFileName 为 文件 名 的 文件 ， 也 可 以 调用 getlnputStream 获 取 InputStream。 如 
果 想 要 使 用 这 种 上 传 方式 还 需要 在 配置 上 传 文件 的 Servlet 时 添加 multipart-config 属 性 ， 例 如 ， 我 们 使 用 的 Spring MVC 中 所 有 的 请 求 都 在 DispatcherServlet 这 个 Servlet 中 ， 所 以 可 以 给 它 配置 上 
multipart-config， 如 下 所 示 : 


<!-- web.xml --> 
<servlet> 
<servlet-name>let'sGo</servlet-name> 
<servlet-class>org.springframework.web.servlet .DispatcherServlet</servlet-class> 
<load-on-startup>1</load-on-startup> 
<multipart-config> 
<location>/tmp</location> 
<max-file-size>-1</max-file-size> 
<max-request-size>-1</max-request-size> 
<file-size-threshold>0</file-size-threshold> 
</multipart-config> 
</servlet> 


multipart-config 有 4 个 子 属性 可 以 配置 ， 下 面 分 别 介绍 : 


“ location: 设置 上 传 文件 存放 的 根 目录 ， 也 就 是 调用 Part 的 wtite (saveFileName) 方法 保存 文件 的 根 目录 。 如 果 saveFileName 带 了 绝对 路 径 ， 将 以 saveFileName 所 带路 径 为 准 。 


* max-file-size: 设置 单个 上 传 文件 的 最 大 值 ， 默 认 值 为 -1， 表 示 无 限制 。 
“ max-request-size; 设置 一 次 上 传 的 所 有 文件 总 和 的 最 大 值 ， 上 默认 值 为 -1 ， 表 示 无 限制 。 


“ file-size-threshold: 设置 不 写 入 硬盘 的 最 大 数据 量 ， 默 认 值 为 0， 表 示 所 有 上 传 的 文件 都 会 作为 一 个 临时 文件 写 入 硬盘 。 


I 


下 面 看 一 下 StandardServletMultipartResolver， 它 的 代码 非常 简单 。 


package org.springframework.web.multipart.support; 
// 省 略 了 imports 
public class StandardServletMultipartResolver implements MultipartResolver { 
private boolean resolveLazily = false; 
public void setResolveLazily (boolean resolveLazily) { 
this.resolveLazily = resolveLazily; 


} 


QOverride 
public boolean isMultipart (HttpServletRequest request) { 
if (!"post".equals (request.getMethod() .toLowerCase())) { 


return false; 
} 
String contentType = request.getContentType(); 
return (contentType != null && contentType.toLowerCase().startsWith("multipart/")); 
} 
QOverride 
public MultipartHttpServletRequest resolveMultipart (HttpServletRequest request) throws MultipartException { 
return new StandardMultipartHttpServletRequest (request, this.resolveLazily); 
} 


QOverride 
public void cleanupMultipart (MultipartHttpServletRequest request) { 
try { 
for (Part part : request.getParts()) { 
if (request.getFile(part.getName()) != null) { 


part.delete(); 
上 


}catch (Exception ex) { 
LogFactory.getLog (getClass () ) .warn("Failed to perform cleanup of multipart items", ex); 
} 


如 何 判 断 是 不 是 上 传 请 求 呢 ? 在 isMultipart 方 法 中 首先 判断 是 不 是 post 请 求 ， 如 果 是 则 再 检查 contentType 是 不 是 以 “multipart/” 开 头 ， 如 果 也 是 则 认为 是 上 传 请 求 。 


resolveMultipart 方 法 直接 将 当前 请 求 封装 成 StandardMultipartHttpServletRequest 并 返回 。 


cleanupMultipart 方 法 删除 了 缓存 。 


下 面 来 看 一 下 StandardMultipartHttpServletRequest。 


//org.springframework.web.multipart.support.StandardMultipartHttpServletRequest 
private void parseRequest (HttpServletRequest request) { 
try { 
~ Collection<Part> parts = request.getParts(); 
this.multipartParameterNames = new LinkedHashSet<String> (parts.size()); 
MultiValueMap<String, MultipartFile> files = new LinkedMultiValueMap<String, MultipartFile> (parts.size()); 
for (Part part : parts) { 
String filename = extractFilename (part .getHeader (CONTENT DISPOSITION)); 
if (filename != null) { 加 
files.add (part.getName () ，new StandardMultipartFile(part, filename)); 
else { 
this.multipartParameterNames .add(Part.getName ()); 


setMultipartFiles (files) 
}catch (Exception ex) { 
throw new MultipartException ("Could not parse multipart servlet request",ex); 


可 以 看 到 ， 它 的 大 概 思路 就 是 通过 request 的 getParts 方 法 获取 所 有 Part， 然 后 使 用 它们 创建 出 File 并 保存 到 对 应 的 属性 ， 以 便 在 处 理 器 中 可 以 直接 调用 。 


17.2 CommonsMultipartResolver 


CommonsMultipartResolver 使 用 了 commons-fileupload 来 完成 具体 的 上 传 操作 。 


在 CommonsMultipartResolver 中 ， 判 断 是 不 是 上 传 请 求 的 isMultipart， 这 将 交 给 commons-fileupload 的 ServletFileUpload 类 完成 ， 代 码 如 下 : 


//org.springframework.web.multipart .commons.CommonsMultipartResolver 
public boolean isMultipart (HttpServletRequest request) { 

return (request != null && ServletFileUpload.isMultipartContent (request)); 
} 


CommonsMultipartResolver 中 实际 处 理 request 的 方法 是 resolveMultipart， 代 码 如 下 : 


//org.springframework.web.multipart .commons.CommonsMultipartResolver 
public MultipartHttpServletRequest resolveMultipart (final HttpServletRequest request) throws MultipartException { 
Assert .notNull (request, "Request must not be null"); 
if (this.resolveLazily) { 
return new DefaultMultipartHttpServletRequest (request) { 
@Override 
protected void initializeMultipart() { 
MultipartParsingResult parsingResult = parseRequest (request); 
setMultipartFiles (parsingResult .getMultipartFiles ()); 
setMultipartParameters (parsingResult .getMultipartParameters ()); 
setMultipartParameterContentTypes (parsingResult .getMultipartParameterContentTypes ()); 
} 
$i 
} else { 
MultipartParsingResult parsingResult = parseRequest (request); 
return new DefaultMultipartHttpServletRequest (request, parsingResult.getMultipartFiles(), 
parsingResult .getMultipartParameters (), parsingResult.getMultipartParameterContentTypes ()); 


它 根 据 不 同 的 resolveLazily 配 置 使 用 了 两 种 不 同 的 方法 ， 不 过 都 是 将 Request 转 换 为 DefaultMultipartHttpServletRequest 类 型 ， 而 且 都 使 用 parseRequest 方 法 进行 处 理 。 


如 果 resolveLazily 为 true， 则 会 将 parsingResult 方 法 放 在 DefaultMultipartHttpServlet-Request 类 重 写 的 initializeMultipart 方 法 中 ，initializeMultipart 方 法 只 有 在 调用 相应 的 get 方 法 (get- 
MultipartFiles、getMultipartParameters 或 getMultipartParameterContentTypes) 时 才 会 被 调用 。 


如 果 resolveLazily 为 false， 则 将 会 先 调用 parseRequest 方 法 来 处 理 request， 然 后 将 处 理 的 结果 传 入 DefaultMultipartHttpServletRequest。 


parseRequest 方 法 是 使 用 ommons-fileupload 中 的 FileUpload 组 件 解析 出 fileltems， 然 后 再 调用 parseFileltems 方 法 将 fileltems 分 为 参数 和 文件 两 类 ， 并 设置 到 三 个 Map 中 ， 三 个 Map 分 别 
参数 、 参 数 的 ContentType 和 上 传 的 文件 ， 代 码 如 下 : 


保存 


//org.springframework.web.multipart .commons.CommonsMultipartResolver 
protected MultipartParsingResult parseRequest (HttpServletRequest request) throws MultipartException { 
String encoding = determineEncoding (request); 
FileUpload fileUpload = prepareFileUpload (encoding); 
try { 
Y List<FileItem> fileItems = ((ServletFileUpload) fileUpload) .parseRequest (request); 
return parseFileItems (fileItems, encoding); 
}atch (FileUploadBase.SizeLimitExceededException ex) { 
throw new MaxUploadSizeExceededException (fileUpload.getSizeMax(), ex); 
}catch (FileUploadException ex) { 
throw new MultipartException("Could not parse multipart servlet request", ex); 
} 
i 
//org.springframework.web.multipart .commons.CommonsFileUploadSupport 
protected MultipartParsingResult ParseFileItems (List<FileItem> fileItems，String encoding) { 
MultiValueMap<String, MultipartFile>multipartFiles=new LinkedMultiValueMap<String,MultipartFile>(); 
Map<String, String[]> multipartParameters = new HashMap<String, String[]>(); 
Map<String, String> multipartParameterContentTypes = new HashMap<String, String>(); 
// 将 fileItems 分 为 文件 和 参数 两 类 ， 并 设置 到 对 应 的 Map 
for (FileItem fileItem : fileItems) { 
// 如 果 是 参数 类 型 
if (fileItem.isFormField()) { 
String value; 
String PartEncoding = determineEncoding (fileItem.getContentType(), encoding); 
if (partEncoding != null) { 
try { 
value = fileItem.getString (partEncoding); 
} catch (UnsupportedEncodingException ex) { 
if (logger.isWarnEnabled()) { 
logger.warn ("Could not decode multipart item '" + fileItem.getFieldName() + 
"1 with encoding '" + partEncoding + "': using Platform default"); 
} 
value = fileItem.getString ()7 
} 
} else { 
Value = fileItem.getString(); 
} 
String[] curParam = multipartParameters.get (fileItem.getFieldName ()); 


if (curParam == null) { 

// 单个 参数 

multipartParameters.put (fileItem.getFieldName(), new String[] {value}); 
} else { 


// 数组 参数 
String[] newParam = StringUtils.addstringToArray (curParam, value); 
multipartParameters.put (fileItem.getFieldName (), newParam); 


} 

// 保存 参数 的 ContentType 

multipartParameterContentTypes.put (fileItem.getFieldqName (), fileItem.getContentType()); 

} else { 

// 如 果 是 文件 类 型 

CommonsMultipartFile file = new CommonsMultipartFile (fileItem) 7 

multipartFiles.add (file.getName (), file); 

if (logger.isDebugEnabled()) { 

logger.debug ("Found multipart file [" + file.getName() + "] of size " + file.getSize() + 

" bytes with original filename [" + file.getOriginalFilename () + "], stored " 十 
file.getStorageDescription()); 


} 
return new MultipartParsingResult (multipartFiles, multipartParameters, multipartParameterContentTypes); 


} 


通过 上 面 这 些 步骤 就 将 request 转 换 为 DefaultMultipartHttpServletRequest 类 型 ， 并 将 解析 出 的 三 类 参数 设置 到 对 应 的 Map。 最 后 来 看 一 下 清理 上 传 缓存 的 方法 。 代 码 如 下 : 


//org.springframework.web.multipart .commons.CommonsMultipartResolver 
public void cleanupMultipart (MultipartHttpServletRequest request) { 
if (request != null) { 
try { 
cleanupFileItems (request .getMultiFileMap ()); 
}catch (Throwable ex) { 
logger.warn ("Failed to perform multipart cleanup for servlet request",ex); 
} 
} 
} 
//org.springframework.web.multipart .commons.CommonsFileUploadSupport 
protected void cleanupFileItems (MultiValueMap<String, MultipartFile> multipartFiles) { 
for (List<MultipartFile> files : multipartFiles.values()) { 
for (MultipartFile file : files) { 
if (file instanceof CommonsMultipartFile) { 


CommonsMultipartFile cmf = (CommonsMultipartFile) file; 
cmf .getFileItem() .delete (); 
if (logger.isDebugEnabled()) { 


logger.debug ("Cleaning up multipart file [" + cmf.getName() + "] with original filename [" +cmf.getOriginalFilename () + "], stored " + cmf.getStorageDescription1( 


清理 缓存 的 cleanupMultipart 方 法 获取 到 request 里 的 multiFileMap (保存 着 上 传 文件 ) 后 将 具体 清理 工作 交 给 了 cleanupFileltems 方 法 ， 后 者 遍历 传 入 的 文件 并 将 它们 删除 ， 因 为 删除 的 是 
MultiValueMap 类 型 ， 所 以 使 用 了 两 层 循环 来 操作 。 
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本 章 分 析 了 MultipartResolver 的 两 个 实现 类 ，MultipartResolver 的 作用 就 是 将 上 传 请 求 包装 成 可 以 直接 获取 File 的 Request， 从 而 方便 操作 。 所 以 MultipartResolver 的 重点 是 从 Request 中 解析 出 上 传 
的 文件 并 设置 到 相应 上 传 类 型 的 Request 中 。 具 体 解析 上 传 文件 的 过 程 使 用 Servlet 的 标准 上 传 和 Apache 的 commons-fileupload 两 种 方式 来 完成 ， 它 们 所 对 应 的 Request 分 别 为 
StandardMultipartHttpServletRequest 和 DefaultMultipartHttpServletRequest 类 型 。 
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LocaleResolver 的 作用 是 使 用 request 解 析出 Locale， 它 的 继承 结构 如 图 18-1 所 示 。 


[ LocaleResolover 


LAcceptHeaderLocaleResolove 


GC AbstractLocaleContextResolver CCookieLocaleResolover 


C SessionLocaleResolver 


C FixedLocaleResolver 


18-1 LocaleResolver 继 承 结构 图 


虽然 LocaleResolver 的 实现 类 结构 看 起 来 比较 复杂 ， 但 是 实现 却 非 常 简单 。 在 LocaleResolver 的 实现 类 中 ，AcceptHeaderLocaleResolver 直 接 使 用 了 Header 里 的 “acceptlanguage” 值 ,不 可 以 在 程 


序 中 修改 ; FixedLocaleResolver 用 于 解析 出 固定 的 Locale， 也 就 是 说 在 创建 时 就 设置 好 确定 的 Locale， 之 后 无 法 修改 ; SessionLocaleResolver 用 于 将 Locale 保 存 到 Session 中 ， 可 以 修改 ; 
CookieLocaleResolver 用 于 将 Locale 保 存 到 Cookie 中 ， 可 以 修改 。 


另外 ， 从 Spring MVC4.0 开 始 ，LocaleResolver 添 加 了 一 个 子 接口 LocaleContextResolver， 其 中 增加 了 获取 和 设置 LocaleContext 的 能 力 ， 并 添加 了 抽象 类 AbstractLocaleContextResolver， 抽 象 类 
添加 了 对 TimeZone 也 就 是 时 区 的 支持 。LocaleContextResolver 接 口 定义 如 下 : 


Package org.springframework.web.servlet; 
// 省 略 了 imports 
public interface LocaleContextResolver extends LocaleResolver { 
LocaleContext resolveLocaleContext (HttpServletRequest request); 
void setLocaleContext (HttpServletRequest request, HttpServiletResponse response, LocaleContext localeContext); 


下 面 分 别 看 一 下 这 些 实现 类 ， 先 来 看 AcceptHeaderLocaleResolver， 这 个 类 直接 实现 的 LocaleResolver 接 口 ， 代 码 非 常 简单 ， 如 下 所 示 : 


package org.springframework.web.servlet.il8n; 
// 省 略 了 imports 
public class AcceptHeaderLocaleResolver implements LocaleResolver { 
@Override 
public Locale resolveLocale (HttpServletRequest request) { 
return request.getLocale(); 


3 
@Override 


Public void setLocale (HttpServletRequest request, HttpServletResponse response, Locale locale) { 
throw new UnsupportedOoperationException( 


"Cannot change HTTP accept header - use a different locale resolution strategy"); 


再 来 看 LocaleResolver 的 抽象 实现 类 AbstractLocaleResolver。 这 个 类 也 很 简单 ， 只 是 添加 默认 Locale 的 defaultLocale 属 性 ， 并 添加 getter/setter 方 法 ， 并 未 实现 接口 方法 ， 代 码 如 下 : 


Package org.springframework.web.servlet.il8n; 

// 省 略 了 imports 

public abstract class AbstractLocaleResolver implements LocaleResolver { 
Private Locale defaultLocale; 
public void setDefaultLocale (Locale defaultLocale) { 


this.defaultLocale = defaultLocale; 
} 
protected Locale getDefaultLocale() { 
return this.defaultLocale; 


} 


下 面 来 看 Spring MVC 新 增加 的 AbstractLocaleContextResolver 类 ， 它 里 面 做 了 两 件 事 : Q@ 添 加 默认 时 区 的 属性 defaultTimeZone， 以 及 其 getter/setter 方 法 ; @ 提 供 LocaleResolver 接 口 的 默认 实 
现 ， 实现 方法 是 使 用 LocaleContext。 代 码 如 下 : 


Package org.springframework.web.servlet.il8n; 
// 省 略 了 imports 
public abstract class AbstractLocaleContextResolver extends AbstractLocale-Resolver implements LocaleContextResolver { 
private TimeZone defaultTimeZone; 
public void setDefaultTimeZone (TimeZone defaultTimeZone) { 
this.defaultTimeZone = defaultTimeZone; 
} 
public TimeZone getDefaultTimeZone() { 
return this.defaultTimeZone; 
} 
@Override 
public Locale resolveLocale (HttpServletRequest request) { 
return resolveLocaleContext (request) .getLocale (); 


于 


@Override 
public void setLocale (HttpServletRequest request, HttpServletResponse response, Locale locale) { 
setLocaleContext (request, response, (locale!=null?new SimpleLocaleContext (locale) : null)); 


} 


剩 下 的 三 个 类 就 是 实际 解析 Locale 的 类 了 ， 下 面 分 别 看 一 下 。 先 来 看 使 用 固定 Locale 的 FixedLocaleResolver。 


Package org.springframework.web.servlet.il8n; 
// 省 略 了 imports 
public class FixedLocaleResolver extends AbstractLocaleContextResolver { 
public FixedLocaleResolver() { 
setDefaultLocale (Locale.getDefault ()); 
} 
public FixedLocaleResolver (Locale locale) { 
setDefaultLocale (locale); 
} 
public FixedLocaleResolver (Locale locale, TimeZone timeZone) { 
setDefaultLocale (locale); 
setDefaultTimeZone (timeZone); 
} 
@Override 
public Locale resolveLocale (HttpServletRequest request) { 
Locale locale = getDefaultLocale(); 
if (locale == null) { 
locale = Locale.getDefault (); 
} 
return locale; 
} 
@Override 
public LocaleContext resolveLocaleContext (HttpServletRequest request) { 
return new TimeZoneAwareLocaleContext() { 
@Override 
public Locale getLocale() { 
return getDefaultLocale () 7 
} 
@Override 
public TimeZone getTimeZone() { 
return getDefaultTimeZone () 7 
} 
}; 
} 
@Override 
public void setLocaleContext (HttpServletRequest request, HttpServiletResponse response, LocaleContext localeContext) { 
throw new UnsupportedOoperationException ("Cannot change fixed locale - use a different locale resolution strategy"); 
} 


FixedLocaleResolver 继 承 自 AbstractLocaleContextResolver， 也 就 具有 了 defaultLocale 和 defaultTimeZone 属 性 。FixedLocaleResolver 在 构造 方法 里 对 这 两 个 属性 进行 了 设 
方法 ， 其 中 ， 如 果 有 Locale、TimeZone 参 数 则 将 


， 它 一 共有 三 个 构造 
设置 为 默认 值 ， 无 参数 的 构造 方法 会 使 用 Locale.getDefault0 作 为 默认 Locale， 这 时 一 般 为 Java 虚 拟 机 所 在 环境 的 Locale， 也 可 以 人 为 修改 。 


resolveLocaleContext 方 法 返回 新 建 的 TimeZoneAwareLocaleContext 匿 名 类 ， 其 中 getLocale 和 getTimeZone 使 用 了 defaultLocale 和 defaultTimeZone。 


加 


setLocaleContext 方 法 不 支持 使 用 ， 相 应 的 setLocale 方 法 也 不 支持 使 用 ， 因 为 它 在 父 类 中 调用 了 setLocaleContext。 也 就 是 说 ， 这 里 的 Locale 和 TimeZone 都 是 不 可 以 修改 的 ， 最 初 设置 的 什么 就 是 什 
么 ， 设 置 之 后 就 不 可 以 修改 。 设 置 Locale 和 TimeZone 的 方法 是 在 配置 FixedLocaleResolver 时 设置 的 ， 可 以 通过 设置 构造 方法 的 参数 来 设置 ， 也 可 以 直接 设置 qdefaultLocale 和 defaultTimeZone 属 性 。 


SessionLocaleResolver 和 FixedLocaleResolver 的 实现 差不多 ， 只 不 过 把 从 默认 值 获取 变 成 从 Session 中 获取 ， 不 过 如 果 获 取 不 到 还 会 使 用 默认 值 。 另 外 SessionLocaleResolver 添 加 了 设置 (也 就 是 修 
改 ) LocaleContext 的 支持 。 解 析 Locale 的 resolveLocale 方 法 代码 如 下 : 


// org.springframework.web.servlet.il8n.SessionLocaleResolver 
public Locale resolveLocale (HttpServletRequest request) { 
Locale locale = (Locale) WebUtils.getSessionAttribute (request, LOCALE SESSION ATTRIBUTE NAME); 
if (locale null) { 
locale = determineDefaultLocale (request); 
下 
return locale; 
} 
protected Locale determineDefaultLocale (HttpServiletRequest request) { 
Locale defaultLocale = getDefaultLocale () ， 
if (defaultLocale == null) { 
defaultLocale = request.getLocale () 7 
} 


return defaultLocale; 


这 里 首先 从 Session 中 获取 ， 如 果 获 取 不 到 会 调用 determineDefaultLocale 方 法 获取 默认 值 ，determineDefaultLocale 方 法 会 先 获取 defaultLocale， 如 果 获 取 不 到 会 调用 Request 的 getLocale 方 法 获 
取 Request 头 的 Locale。 


解析 LocaleContext 的 方法 除 resolveLocale 方 法 外 ， 还 可 以 使 用 resolveLocaleContext 方 法 ， 它 和 前 者 的 解析 方式 一 样 ， 只 是 在 前 者 的 基础 上 增加 了 对 TimeZone 解 析 的 内 容 ， 代 码 如 下 : 


// org.springframework.web.servlet.il8n.SessionLocaleResolver 
public LocaleContext resolveLocaleContext (final HttpServletRequest request) { 
return new TimeZoneAwareLocaleContext() { 
Q@Override 
Public Locale getLocale() { 
Locale locale = (Locale) WebUtils.getSessionAttribute (request, LOCALE SESSION ATTRIBUTE NAME); 
if (locale == null) { 
locale = determineDefaultLocale (request); 
} 


return locale; 


QOverride 
Public TimeZone getTimeZone() { 


TimeZone timeZone = (TimeZone) WebUtils.getSessionAttribute (request, TIME ZONE SESSION ATTRIBUTE NAME); 


if (timeZone = null) { 
timeZone = determineDefaultTimeZone (request); 
} 
return timeZone; 
- 
}; 
} 
protected TimeZone determineDefaultTimeZone (HttpServletRequest request) { 
return getDefaultTimeZone(); 
} 


其 中 解析 TimeZone 的 过 程 和 解析 Locale 的 过 程 一 样 ， 先 从 Session 中 获取 ， 如 果 获 取 不 到 则 使 用 默认 值 。 


下 面 看 一 下 设置 LocaleContext 的 setLocaleContext 方 法 ， 代 码 如 下 : 


// org.springframework.web.servlet.il8n.SessionLocaleResolver 


public void setLocaleContext (HttpServletRequest request, HttpServletResponse response, LocaleContext localeContext) { 


Locale locale = null; 
TimeZone timeZone = null; 
if (localeContext != null) { 

locale = localeContext .getLocale(); 

if (localeContext instanceof TimeZoneAwareLocaleContext) { 

timeZone = ((TimeZoneAwareLocaleContext) localeContext) .getTimeZone(); 

} 
} 
WebUtils.setSessionAttribute (request, LOCALE SESSION ATTRIBUTE NAME, locale); 
WebUtils. setSessionAttribute (request, TIME ZONE SESSION ATTRIBUTE NAME, timeZone); 


这 里 先 从 LocaleContext 中 获取 Locale 和 TimeZone， 然 后 设置 到 Session 中 。 


SessionLocaleResolver 就 分 析 完 毕 。CookieLocaleResolver 和 SessionLocaleResolver 的 处 理 方式 非常 相似 ， 只 是 将 Session 变 成 Cookie 来 保存 属性 。 另 外 由 于 CookieLocaleResolver 为 了 处 理 Cookie 
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ThemeResolver 用 于 根据 request 解 析 Theme， 其 继承 结构 如 图 19-1 所 示 。 


4 网 ThemeResolver 
a GB AbstractThemeResolver 
(9 FixedThemeResolver 


方便 而 继承 了 CookieGenerator， 所 以 它 就 不 能 继承 AbstractLocaleContextResolver， 不 过 它 仍 然 提 供 保 存 默认 Locale 和 TimeZone 的 属性 defaultLocale 和 defaultTimeZone， 这 只 是 自己 定义 的 , 具体 
代码 就 不 叙述 了 。 


(9 SessionThemeResolver 
(3 CoolieThemeResolver 


图 19-1 ThemeResolver 继 承 结构 图 


ThemeResolver 的 实现 和 LocaleResolver 非 常 相似 ， 而 且 继 承 结构 也 非常 相似 ， 不 过 没有 像 LocaleResolver 那 样 添加 新 的 子 接 


， 所 以 相对 来 说 要 更 简单 。 


AbstractThemeResolver 设 置 了 默认 主题 名 defaultTheme-Name 属 性 ， 并 提供 了 其 getter/setter 方 法 ，defaultThemeName 的 默认 值 为 “theme”， 代 码 如 下 : 


package org.springframework.web.servlet.theme; 
import org.springframework.web.servlet.ThemeResolver; 
public abstract class AbstractThemeResolver implements ThemeResolver { 
public final static String ORIGINAL DEFAULT THEME NAME = "theme"; 
private String defaultThemeName = ORIGINAL DEFAULT THEME NAME.; 
public void setDefaultThemeName (String defaultThemeName) { 
this.defaultThemeName = defaultThemeName; 


} 

public String getDefaultThemeName () { 
return this.defaultThemeName; 

} 


FixedThemeResolver 用 于 解析 固定 的 主题 名 ， 主 题名 在 创建 时 设置 ， 不 能 修改 。 其 实 就 是 设置 一 个 固定 的 


题 ， 代 码 如 下 : 


package org.springframework.web.servlet.theme; 

import javax.servlet.http.HttpServletRequest; 

import javax.servlet.http.HttpServletResponse; 

Public class FixedThemeResolver extends AbstractThemeResolver { 
QOverride 


public String resolveThemeName (HttpServletRequest request) { 
return getDefaultThemeName (); 
} 
QOverride 
public void setThemeName (HttpServletRequest request, HttpServletResponse response, String themeName) { 
throw new UnsupportedOperationException ("Cannot change theme - use a different theme resolution strategy"); 


} 


SessionThemeResolver 将 主题 保存 到 Session 中 ， 可 以 修改 ,代码 如 下 : 


package org.springframework.web.servlet.theme; 
// 省 略 了 imports 
Public class SessionThemeResolver extends AbstractThemeResolver { 
public static final String THEME SESSION ATTRIBUTE NAME = SessionThemeResolver.class.getName() + ".THEME"; 
QOverride 
public String resolveThemeName (HttpServletRequest request) { 
String themeName = (String) WebUtils.getSessionAttribute (request, THEME SESSION ATTRIBUTE NAME); 
// A specific theme indicated, or do we need to fallback to the default? ee 
return (themeName != null ? themeName : getDefaultThemeName ()); 


QOverride 
public void setThemeName (HttpServletRequest request, HttpServletResponse response, String themeName) { 
WebUtils.setSessionAttribute (request, THEME SESSION ATTRIBUTE NAME, 


(StringUtils.hasText (themeName) ? themeName : null)); 


CookieThemeResolver 将 主题 保存 到 Cookie 中 ， 它 为 了 处 理 Cookie 方 便 而 继承 了 Cookie-Generator， 所 以 就 不 能 继承 AbstractThemeResolver 了 ， 它 自己 实现 了 对 默认 主题 的 支持 ， 解 析 和 设置 主 
题 的 接口 方法 如 下 : 


//org.springframework.web.servlet.theme.CookieThemeResolver 
public String resolveThemeName (HttpServletRequest request) { 
// 检查 是 否 已 经 存在 request 的 属性 中 
String themeName = (String) request.getAttribute (THEME REQUEST ATTRIBUTE NAME); 
if (themeName != null) { 
return themeName; 


} 
// 从 Cookie 中 获取 主题 
Cookie cookie = WebUtils.getCookie (request, getCookieName () ) 7 
if (cookie != null) { 
String value = cookie.getValue(); 
if (StringUtils.hasText (value)) { 
themeName = value; 


} 


} 
// 如 果 没 获取 到 则 使 用 默认 值 
if (themeName == null) 1{ 
themeName = getDefaultThemeName () 7 


} 

// 将 获得 的 主题 设置 到 request 的 属性 

request .setAttribute (THEME REQUEST ATTRIBUTE NAME, themeName); 
return themeName; 


QOverride 
public void setThemeName (HttpServletRequest request, HttpServletResponse response, String themeName) { 
if (StringUtils.hasText (themeName)) { 
// 如 果 传 入 的 主题 不 为 空 则 设置 到 request 并 添加 到 Cookie 
request .setAttribute (THEME REQUEST ATTRIBUTE NAME, themeName); 
addCookie (response, themeName); 加 
} else { 
// 如 果 传 入 的 主题 为 空 则 将 默认 主题 设置 到 request 并 删除 主题 相应 Cookie 
request .setAttribute (THEME, REQUEST _ ATTRIBUTE NAME, getDefaultThemeName () ) 7 
removeCookie (response) 


处 理 过 程 中 会 将 解析 到 的 主题 设置 到 request 的 属性 中 以 方便 使 用 。 设 置 (修改 ) 主题 时 ， 如 果 传 入 的 主题 为 空 则 将 删除 主题 相应 的 Cookie。 
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FlashMapManager 用 来 管理 FlashMap，FlashMap 用 于 在 redirect 时 传递 参数 ， 前 面 已 经 介绍 过 。FlashMapManager 的 继承 结构 如 


20-1 所 示 。 
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图 20-1 ”FlashMapManager 继 承 结构 图 


在 Spring MVC 中 FlashMapManager 的 实现 结构 非常 简单 ， 一 个 抽象 类 和 一 个 具体 实现 类 ， 抽 象 类 采用 模板 模式 定义 了 整体 流程 ， 具 体 实现 类 SessionFlashMapManager 通 过 模板 方法 提供 了 具体 操 
作 FlashMap 的 功能 。 


在 具体 分 析 代 码 前 先 说 明 两 点 : 第 一 ， 实 际 在 Session 中 保存 的 FlashMap 是 List<FlashMap> 类 型 ， 也 就 是 说 ， 一 个 Session 可 以 保存 多 个 FlashMap， 一 个 FlashMap 保 存 着 一 套 Redirect 转 发 所 传递 的 
参数 ; 第 二 ，FlashMap 继 承 自 HashMap， 它 除了 具有 HashMap 的 功能 和 设置 有 效 期 ， 还 可 以 保存 Redirect 后 的 目标 路 径 和 通过 url 传 递 的 参数 ， 这 两 项 内 容 主要 用 来 从 Session 保 存 的 多 个 FlashMap 中 查 
找 当 前 请 求 的 FlashMap。 


明白 上 面 两 点 AbstractFlashMapManager 后 就 容易 分 析 了 ， 下 面 先 来 看 保存 FlashMap 的 saveOutputFlashMap 方 法 。 


// org.springframework.web.servlet.support.AbstractFlashMapManager 
public final void saveOutputFlashMap (FlashMap flashMap, HttpServletRequest request, HttpServletResponse response) { 
if (CollectionUtils.isEmpty (flashMap)) { 
return; 


} 

// 首先 对 flashMap 中 的 转发 地 址 和 参数 进行 编码 ， 这 里 的 request 主 要 用 来 获取 当前 编码 方式 
String path = decodeAndNormalizePath (flashMap.getTargetRequestPath(), request); 
flashMap.setTargetRequestPath (path); 
decodeParameters (flashMap.getTargetRequestParams (), request); 
if (logger.isDebugEnabled()) { 

logger.debug ("Saving FlashMap=" + flashMap); 


} 
// 设置 有 效 其 
flashMap.startExpirationPeriod (getFlashMapTimeout ()); 
// 用 于 获取 互 斥 变量 ， 是 模板 方法 ， 如 果子 类 返回 值 不 为 hul1 则 同步 执行 ， 否 则 不 需要 同步 
Object mutex = getFlashMapsMutex (request); 
if (mutex != null) { 
synchronized (mutex) { 
// 取 回 保存 的 List<FlashMap>， 如 果 没 获取 到 则 新 建 一 个 ， 然 后 添加 现 有 的 flashMap 
// retrieveFlashMaps 方 法 用 于 获取 List<FlashMap>， 是 模板 方法 ， 子 类 实现 
List<FlashMap> allFlashMaps = retrieveFlashMaps (request); 
allFlashMaps = (allFlashMaps != null ? allFlashMaps : new CopyOnWriteArrayList <FlashMap>()); 
allFlashMaps .add (flashMap); 
// 将 添加 完 的 List<FlashMap> 更 新 到 存储 介质 ， 是 模板 方法 ， 子 类 实现 
updateFlashMaps (allFlashMaps, request, response); 
} 
jelse { 
List<FlashMap> allFlashMaps = retrieveFlashMaps (request); 
allFlashMaps = (allFlashMaps != null ? allFlashMaps : new LinkedList<FlashMap>()); 
allFlashMaps.add (flashMap); 
updateFlashMaps (allFlashMaps, request, response); 


整个 过 程 是 这 样 的 ， 首 先 对 flashMap 中 的 目标 地 址 和 url 参 数 进行 编码 ， 编 码 格式 使 用 当前 request 获 取 ; 其 次 设置 有 效 期 ， 有 效 期 可 以 通过 flashMapTimeout 参 数 配置 ， 默 认 值 是 180 秒 ;然后 将 
flashMap 添 加 到 整体 的 List<FlashMap> 中 并 更 新 。 


最 后 一 步 添加 到 List<FlashMap> 中 并 更 新 的 过 程 首先 通过 模板 方法 getFlashMapsMutex 效 取 互 斥 变量 ， 如 果 可 以 获取 到 则 使 用 同步 方式 更 新 ， 如 果 获取 不 到 则 不 使 用 同步 。 更 新 过 程 是 先 将 原来 保存 
的 List<FlashMap> 获 取 到 ， 如 果 原 来 没有 则 新 建 一 个 ， 然 后 将 现在 的 flashMap 添 加 进去 再 调用 updateFlashMaps 模 板 方法 进行 更 新 。retrieveFlashMaps、getFlashMapsMutex 和 updateFlashMaps 方 
法 都 在 子 类 SessionFlashMapManager 中 实现 ， 代 码 如 下 : 


// org.springframework.web.servlet .support.SessionFlashMapManager 
protected List<FlashMap> retrieveFlashMaps (HttpServletRequest request) { 


HttpSession session = request.getSession (false); 


return (session != null ? (List<FlashMap>) session.getAttribute (FLASH MAPS SESSION ATTRIBUTE) : null); 


} 


protected void updaterFlashMaps (List<FlashMap> flashMaps, HttpServletRequest request, HttpServletResponse response) { 
WebUtils.setSessionAttribute (request, FLASH MAPS SESSION ATTRIBUTE, (!flashMap 


} 
QOverride 


protected Object getFlashMapsMutex (HttpServletRequest request) { 
return WebUtils.getSessionMutex (request .getSession()); 


} 


s.isEmpty() ? flashMaps : null)); 


它们 都 是 使 用 WebUtils 对 Session 进 行 操作 的 。 


下 面 介绍 获取 flashMap 的 retrieveAndUpdate 方 法 ， 代 码 如 下 : 


// org.springframework.web.servlet .support.AbstractFlashMapManager 

public final FlashMap retrieveAndUpdate (HttpServiletRequest request, HttpServletResponse response) { 
// 从 存储 介质 中 获取 List<FlashMap>， 是 模板 方法 ， 子 类 实现 
List<FlashMap> allFlashMaps = retrieveFlashMaps (request); 


if (CollectionUtils.isEmpty(allFlashMaps)) { 
return null; 
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if (logger.isDebugEnabled()) { 


logger.debug ("Retrieved FlashMap(s): " + allFlashMaps); 


: 
// 检查 过 期 的 ElashMap， 并 将 它们 设置 到 mapsToRemove 变 量 


List<FlashMap> mapsToRemove = getExpiredFlashMaps (allFlashMaps); 


// 获取 与 当前 request 匹 配 的 ELlashMap， 并 设置 到 match 变 量 


FlashMap match = getMatchingFlashMap (allFlashMaps, request); 


// 如 果 有 匹配 的 则 将 其 添加 到 mapsToRemove， 待 下 面 删 除 


if (match != null) { 
mapsToRemove .add (match); 


于 
// 删除 mapsToRemove 中 保存 的 变量 
if (!mapsToRemove .isEmpty()) { 
if (logger.isDebugEnabled()) { 


logger.debug ("Removing FlashMap(s): " + mapsToRemove); 


有 


Object mutex = getFlashMapsMutex (request); 


if (mutex != null) { 
synchronized (mutex) { 


allFlashMaps = retrieveFlashMaps (request); 


if (allFlashMaps != null) { 


allFlashMaps .removeAll (mapsToRemove); 


updateFlashMaps (allFlashMaps, request, response); 


} 
} 
}else { 
allFlashMaps .removeAll (mapsToRemove); 


updateFlashMaps (allFlashMaps, request, response); 


} 


return match; 


整个 过 程 是 这 样 的 : 首先 使 用 retrieveFlashMaps 模 板 方法 获取 List<FlashMap>; 然后 检查 其 
getMatchingFlashMap 方 法 从 获取 的 List<FlashMap> 中 找 出 和 当前 request 相 


request 匹 配 的 返回 。 


查找 与 当前 Request 相 匹配 的 FlashMap 的 getMatchingFlashMap 方 法 ， 代 码 如 下 : 


中 已 经 过 期 的 FlashMap 并 保存 ， 检 查 方法 通过 保存 时 设置 的 过 期 时 间 进行 判断 ;接着 调 


匹配 的 FlashMap; 最 后 将 过 期 的 和 与 当前 请 求 相 匹配 的 FlashMap 从 List<FlashMap> 中 删除 并 更 新 到 Session 中 ， 将 与 当前 


// org.springframework.web.servlet.support.AbstractFlashMapManager 
private FlashMap getMatchingFlashMap (List<FlashMap> allMaps, HttpServletRequest request) { 
List<FlashMap> result = new LinkedList<FlashMap>(); 


for (FlashMap flashMap : allMaps) { 


if (isFlashMapForRequest (flashMap, request)) 


result .add (flashMap); 
} 
if (!result.isEmpty()) { 
Collections.sort (result); 
if (logger.isDebugEnabled()) { 


logger.debug ("Found matching FlashMap(s): 


return result.get (0); 


return null; 


" + result); 


匹配 则 保存 到 临时 变量 result， 遍 历 完 后 可 能 会 有 多 个 匹配 的 结果 ， 最 后 将 它们 排序 并 返 


这 
| 


这 里 遍历 了 所 有 的 FlashMap 然 后 调用 isFlashMapForRequest 方 法 实际 检查 是 否 匹 配 ， 如 果 | 


个 ，isFlashMapForRequest 方 法 代码 如 下 : 


// org.springframework.web.servlet.support.AbstractFlashMapManager 

protected boolean isFlashMapForRequest (FlashMap flashMap, HttpServletRequest request) { 
// 检查 目标 路 径 ， 如 果 FlashMap 中 保存 的 路 径 和 Request 不 匹配 则 返回 false 
String expectedPath = flashMap.getTargetRequestPath(); 


if (expectedPath != null) { 


String requestUri = getUrlPathHelper() .getOriginatingRequestUri (request); 
if (!requestUri.equals (expectedPath) && !requestUri.equals (expectedPath + "™/")) { 


return false; 


} 


} 
// 检查 参数 ， 如 果 FlashMap 中 保存 的 Url 参数 在 Request 中 没有 则 返回 false 


MultiValueMap<String, String> targetParams = 


{ 


for (String expectedValue : targetParams .get (expectedName)) { 
if (!ObjectUtils.containsElement (request .getParameterValues (expectedName), expectedValue)) { 


return false; 
} 
} 
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return true; 


flashMap.getTargetRequestParams (); 
for (String expectedName : targetParams .keySet () ) 


这 里 的 检查 方法 就 是 通过 FlashMap 中 保存 的 目标 地 址 和 url 参 数 与 Request 进 行 比较 的 ， 如 果 保 存 的 目标 地 址 和 Request 的 url 以 及 url+ “/” 都 不 一 样 则 返回 false， 如 果 FlashMap 中 保存 的 url 参 数 在 


回 


Request 中 没有 也 返 | 


整个 取 回 FlashMap 的 过 程 分 析 完 毕 ， 从 这 里 可 以 看 出 两 件 导 
秒 ， 但 是 如 果 在 更 长 的 时 间 内 没有 过 取 回 FlashMap 的 操作 ， 那 么 即使 过 期 也 不 会 被 删除 ;@ 使 有 
的 。 不 过 这 并 不 会 造成 什么 影响 ， 因 为 这 里 的 FlashMap 正 常情 况 下 只 有 一 个 ， 参 数 使 用 完 后 会 自 
与 的 ， 时 间 一 般 会 很 短 ， 而 且 即 使 过 期 了 也 不 会 有 什么 影响 。 


false， 如 果 这 两 项 都 合格 则 返回 true。 


有 有情: @ 每 次 取 回 


FlashMap 时 都 会 对 所 有 保存 的 参数 检查 是 否 过 期 ， 而 且 只 有 在 取 回 的 时 候 才 会 检查 ， 也 就 是 说 虽然 设置 的 过 期 时 间 是 180 


request 匹 配 FlashMap 是 在 所 有 的 FlashMap 中 进行 的 ， 也 就 是 说 其 结果 可 能 包含 已 经 过 期 但 还 没有 被 删除 


区 


这 


动 删除 ， 所 以 全 部 遍历 也 不 会 有 什么 问题 ， 另 外 FlashMap 主 要 用 在 redirect 中 ， 这 个 过 程 是 不 需要 人 工 参 


对 FlashMapManager 的 分 析 就 讲 完 了 。 


第 四 篇 ”总结 与 补充 


前 面 三 篇 已 经 将 Spring MVC 的 源 代 码 分 析 完毕 ， 本 篇 主要 对 前 面 的 内 容 做 一 个 总 结 ， 另 外 再 将 异步 请 求 相关 的 内 容 给 大 家 做 个 补充 。 


学 习 完 一 样 东西 之 后 及 时 地 总 结 可 以 在 很 短 的 时 间 内 获得 很 大 的 收获 ， 这 不 仅 适用 于 开源 框架 的 学 习 ， 同 时 也 适用 于 其 他 内 容 的 学 习 。 这 么 做 首先 可 以 加 深 对 所 学 内 容 的 印象 ， 更 重要 的 是 可 以 站 在 更 
高 的 层次 来 综合 思考 ， 这 样 就 可 以 将 所 学 的 内 容 整 合 到 一 个 整体 结构 中 ， 并 且 这 时 候 很 容易 想 明白 原来 没 理解 的 疑点 ， 也 就 是 所 谓 的 将 书 “ 先 看 厚 再 看 薄 ” 中 看 薄 的 过 程 。 


异步 请 求 是 现在 比较 热门 的 一 种 技术 ，Spting MVC 也 提供 了 对 它 的 支持 ， 不 过 它 的 异步 请 求 处 理 过 程 是 分 散在 整个 请 求 处 理 过 程 的 各 个 环节 中 的 ， 所 以 如 果 在 分 析 SpringMVC 怎 么 处 理 请 求 之 前 讲解 异 
步 处 理会 比较 困难 ， 另 外 异步 请 求 有 其 独立 的 处 理 方式 ， 如 果 将 它 的 内 容 分 散 到 对 SpringMVC 分 析 的 过 程 中 讲解 将 会 加 大 大 家 对 SpringMVC 理 解 的 难度 ， 所 以 单独 将 这 部 分 内 容 通 过 补充 的 形式 放 在 最 后 讲 


解 给 大 家 。 


第 21 章 ”总结 


本 章 将 对 前 面 所 分 析 的 内 容 进 行 总 结 和 回顾 。 首 先 总 结 一 下 Spring MVC 的 运行 原理 ， 然 后 通过 实际 跟踪 一 个 请 求 来 回顾 整个 处 理 过 程 。 


21.1 Spring MVC 原 理 总 结 


Spring MVC 的 本 质 是 一 个 Servlet，Servlet 的 运行 需要 一 个 Servlet 容 器 ， 如 常用 的 Tomcat。Servlet 容 器 帮 我 们 统一 做 了 像 底层 Socket 连 接 那 种 通用 但 又 很 麻烦 的 工作 ， 让 我 们 开发 网 站 程序 变 得 简 
单 ， 只 需要 按照 Servlet 的 接口 去 做 就 可 以 了 ， 而 Spring MVC 又 在 此 基础 上 提供 了 一 套 通用 的 解决 方案 ， 这 样 我 们 连 Servlet 都 不 用 写 了 ， 而 只 需要 写 最 核心 的 业务 就 可 以 了 ， 而 且 Spring MVC 的 使 用 非常 
灵活 ， 几 乎 可 以 说 ， 只 要 我 们 能 想到 的 用 法 ，Spring MVC 都 可 以 做 到 。 


为 了 让 大 家 更 好 地 理解 Spring MVC， 我 们 开始 以 Tomcat 为 例 分 析 Servlet 容 器 的 结构 和 原理 。Tomcat 可 以 分 为 两 大 部 分 : 连接 器 和 容器 ， 连 接 器 专门 用 于 处 理 网 络 连接 相关 的 事情 ， 如 Socket 连 接 、 
request 封 装 、 连 接线 程 池 维护 等 工作 ， 容 器 用 来 存放 我 们 编写 的 网 站 程序 ，Tomcat 中 一 共有 4 层 容 器 : Engine、Host、Context 和 Wrapper。 一 个 Wrapper 对 应 一 个 Servlet， 一 个 Context 对 应 一 个 应 
， 一 个 Host 对 应 一 个 站 点 ，Engine 是 引擎 ， 一 个 容器 只 有 一 个 。Context 和 Host 的 区 别 是 Host 代 表 站 点 ， 如 不 同 的 域名 ， 而 Context 表 示 一 个 应 用 ， 比 如 ， 默 认 情 况 下 ebapps\ROOT 中 存放 的 为 主 应 
， 对 应 一 个 站 点 的 根 路 径 ， 如 www.excelib.com。webapps 下 别 的 目录 则 存放 别 的 子 应 用 ， 对 应 站 点 的 子路 径 ， 如 webapps/test 目 录 存 放 着 www.excelib.com/test 应 用 ， 而 所 有 webapps 下 的 应 用 都 属 
于 同一 个 站 点 ， 它 们 每 一 个 都 对 应 一 个 Context， 如 果 想 添加 一 个 新 站 点 ， 如 blog.excelib.com， 则 需要 使 用 Host。 一 套 容器 和 多 个 连接 器 组 成 一 个 Service， 一 个 Tomcat 中 可 以 有 多 个 Service。 


Servlet 接 口 一 共 定义 了 5 个 方法 ， 其 中 init 方 法 和 destroy 用 于 初始 化 和 销毁 Servlet， 整 个 生命 周期 中 只 会 被 调用 一 次 ; service 方 法 实际 处 理 请 求 ; getServletConfig 方 法 返回 的 ServletConfig， 可 以 获 
取 到 配置 Servlet 时 使 用 init-param 配 置 的 参数 ， 还 可 以 获取 ServletContext; getServletlnfo 方 法 可 以 获取 到 一 些 Servlet 相 关 的 信息 ， 如 作者 、 版 权 等 ， 这 个 方法 需要 自己 实现 ， 默 认 返 回 空 字符 串 。 


Java 提 供 了 两 个 Servlet 的 实现 类 : GenericServlet 和 HttpServlet。GenericServlet: 做 了 三 件 事 : @ 实 现 了 ServletConfig 接 口 ， 让 我 们 可 以 直接 调用 ServletConfig 中 的 方法 ; @ 提 供 了 无 参 的 init 方 
法 ; @ 提 供 了 log 方 法 。HttpServlet 主 要 做 了 两 件 事 : @ 将 ServletRequest 和 ServletResponse 转 换 为 了 HttpServletRequest 和 HttpServletResponse; @ 根 据 Http 请 求 类 型 (如 Get、Post 等 ) 将 请 求 路 由 
到 了 7 个 不 同 的 处 理 方法 ， 这 样 在 编写 代码 时 只 需要 将 不 同类 型 的 处 理 代码 编写 到 不 同 的 方法 中 就 可 以 了 ， 如 常见 的 doGet、doPost 方 法 就 是 在 这 里 定义 的 。 


Spring MVC 的 本 质 是 个 Servlet， 这 个 Servlet 继 承 自 HttpServlet。Spring MVC 中 提供 了 三 个 层次 的 Servlet: HttpServletBean、FrameworkServlet#0DispatcherServlet， 它 们 相互 继 
承 ，HttpServletBean 直 接 继承 自 Java 的 HttpServlet。HttpServletBean 用 于 将 Servlet 中 配置 的 参数 设置 到 相应 的 属性 中 ，FrameworkServlet 初 始 化 了 Spring MVC 中 所 使 用 的 WebApplication- 
Context， 具 体 处 理 请 求 的 9 大 组 件 是 在 DispatcherServlet 中 初始 化 的 。 整 个 Servlet 继 承 结构 如 图 21-1 所 示 。 


TservletConfig 
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TEnvironmentAware 


TApplicationContextAwar 


Java 


C FrameworkServlet 


C DispatcherServlet 


图 21-1 Spring MVC 框 架 中 Servlet 继 承 结构 图 


Spring MVC 的 结构 就 总 结 到 这 里 ， 接 下 来 总 结 Spring MVC 的 请 求 处 理 过 程 。Spring MVC 中 请 求 的 处 理 主要 在 DispatcherServlet 中 ， 不 过 它 上 一 层 的 FrameworkServlet 也 做 了 一 些 工 作 ， 首 先 它 将 


所 有 类 型 的 请 求 都 转发 到 processRequest 方 法 ， 然 后 在 processRequest 方 法 中 做 了 三 件 事 : @ 调 用 了 doService 模 板 方法 具体 处 理 请 求 ，doService 方 法 在 DispatcherServlet 中 实现 ; @ 将 当前 请 求 的 
LocaleContext 和 ServletRequestAttributes 在 处 理 请 求 前 设置 到 了 LocaleContextHolder 和 RequestContextHolder， 并 在 请 求 处 理 完成 后 恢复 ;@ 请 求 处 理 完 后 发 布 一 个 ServletRequestHandledEvent 


类 型 的 消息 。 


请 求 交 给 doDispatch 方 法 进行 具体 处 理 。 


DispatcherServlet 在 doServic 方 法 中 将 webApplicationContext、localeResolver、theme-Resolver、themeSource、FlashMap 和 FlashMapManager 设 置 到 request 的 属性 中 以 方便 使 用 ， 然 后 将 


DispatcherServlet 的 doDispatch 方 法 按 执 行 过 程 大 致 可 以 分 为 4 步 : @ 根 据 request 找 到 Handler; @ 根 据 找到 的 Handler 找 到 对 应 的 HandlerAdapter; @ 用 HandlerAdapter 调 用 Handler 处 理 请 求 ; 


@ 调 用 processDispatchResult 方 法 处 理 Handler 处 理 之 后 的 结果 (主要 处 理 异 常 和 找到 View 并 泻 染 输出 给 用 户 ) 。 这 4 步 中 的 每 一 步 又 有 自己 复杂 的 处 理 过程 ， 详 细 内 容 这 里 就 不 介绍 了 ，21.2 节 会 再 和 大 


家 一 起 回顾 。 


解 为 使 用 工具 的 人 。 


对 本 书 所 讲 内 容 的 回顾 就 说 到 这 里 


但 总 结 并 没有 结束 ， 我 们 还 应 该 站 在 全 局 的 角度 来 仔细 体会 Spring MVC 的 设计 理念 ， 这 才 是 最 重要 的 ， 只 有 做 到 了 这 一 步 才 可 以 说 将 Spring MVC 看 透 了 。 


前 面 介绍 过 Handler、HandlerMapping 和 HandlerAdapter 的 关系 ，Handler 是 具体 干 活 的 工具 ，HandlerMapping 用 来 找 出 需要 的 Handler，HandlerAdapter 是 怎么 具体 使 用 Handler 干 活 ， 可 以 理 


一 般 做 事情 都 是 这 个 步骤 ， 先 找到 工具 ， 然 后 找到 使 用 工具 的 人 ， 最 后 人 使 用 工具 干 活 。 这 种 思想 就 是 Spring MVC 的 灵魂 ， 它 贯穿 整个 Spring MVC。 上 面 说 的 Handler 是 MVC 中 的 C 层 ， 其 实 Spring 


MVC 在 MVC 三 层 使 用 的 都 是 这 种 思想 ， 在 V 层 也 就 是 View 层 干 活 的 工具 是 View， 查 找 View 使 用 的 是 ViewResolver 和 RequestToViewNameTranslator， 因 为 View 是 标准 的 格式 ， 使 用 非常 简单 ， 所 以 就 
没有 “使 用 的 人 ”这 个 角色 ;在 M 层 也 就 是 Model 层 ， 这 层 干 活 的 就 多 了 ， 注 释 了 @ModelAttribute 的 方法 、SessionAttribute、FlashMap、Model 以 及 需要 执行 的 方法 的 参数 和 返回 值 等 都 属于 这 一 


层 


，HandlerMethodArgumentResolver 和 HandlerMethodReturnValueHandler、ModelFactory 和 FlashMapManager 是 这 一 层 中 “使 用 的 人 ”，HandlerMethodArgumentResolver 和 


HandlerMethodReturnValueHandler 同 时 还 担任 着 “查找 工具 ”的 角色 。 


先 


因为 Model 层 贯穿 于 Controller 层 和 View 层 之 中 ， 所 以 很 容易 将 其 当 作 那 两 层 中 的 内 容 ， 其 实 Model 层 才 是 Spring MVC 最 复杂 的 地 方 。 


通过 慢 慢 体会 Spring MVC 中 MVC 三 层 的 三 个 角色 可 以 让 我 们 对 Spring MVC 理 解 得 更 加 深入 ， 真 正 将 其 看 透 。 当 然 ， 深 入 体会 的 基础 是 需要 先 将 各 个 组 件 的 功能 和 实现 方法 弄 明白 ， 也 就 是 只 有 
“把 书 看 厚 ” 然 后 才 可 以 “看 薄 ”。 


21.2 ”实际 跟踪 一 个 请 求 


本 节 通 过 实际 跟踪 一 个 请 求 来 完整 梳理 Spring MVC 的 请 求 处 理 过 程 。 


这 里 给 大 家 设计 了 一 个 给 文章 做 评论 的 例子 ， 大 致 流程 是 先 去 掉 评论 中 的 敏感 词 ， 然 后 保存 到 数据 库 ， 接 着 redirect 到 一 个 显示 结果 的 处 理 器 ， 在 其 中 通过 文章 1d 获取 文章 标题 和 文章 内 容 ， 最 后 显示 到 


页 


面 。 这 个 例子 中 用 到 @ModelAttribute 注 释 的 方法 、@SessionAttributes 注 释 、PathVariable 参 数 、Model 参 数 、redirect 转 发 等 。 另 外 ， 这 里 的 主要 目的 是 跟踪 Spring MVC 的 请 求 ， 所 以 就 不 实际 操 


作 数 据 库 了 ， 保 存 评论 的 语句 省 略 ， 通 过 1d 获 取 文 章 标题 和 内 容 是 直接 使 用 ld+ “号 文章 标题 ”和 Id+ “号 文章 内 容 ” 来 模拟 的 。 


下 面 创 建 示例 程序 ， 首 先 在 web.xml 中 配置 Spring MVC， 代 码 如 下 : 


<!-- web.xml --> 
<servlet> 
<servlet-name>followMe</servlet-name> 
<servlet-class>org.springframework.web.servlet .DispatcherServlet</servlet-class> 
<init-param> 
<param-name>contextConfigLocation</param-name> 


<param-value>classpath:followMe.xml</param-value> 
</init-param> 
<load-on-startup>1</l0ad-on-startup> 
</servlet> 
<servlet -mapping> 
<servlet-name>followMe</servlet-name> 
<url-pattern>/</url-pattern> 
</servlet-mapping> 


这 里 配置 了 一 个 followMe 的 Servlet， 它 的 配置 文件 为 classpath 下 的 followMe.xml 文 件 ， 其 内 容 如 下 : 


<?xml version="1.0" encoding="UTF-8"?> 

<beans xml http://www.springframework.org/schema/beans" 
xmlns:xsi="http://www.w3.0org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p" 
xmlns:context="http://www.springframework.org/schema/context" 
xmlns:mve="http://www.springframework.org/schema/mve" 
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd 
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context .xsd 
http://www.springframework.org/schema/mve http://www.springframework.org/schema/mvc/spring-mvce.xsd"> 

<context :component-scan base-package="com.excelib" /> 

<mvc:annotation-driven /> 

<mvc:view-resolvers> 

<bean class="org.springframework.web.servlet .view.InternalResourceViewResolver™" 


p:prefix="/WEB-INF/views/jsp/" 
p:suffix=".jsp"/> 
</mve:view-resolvers> 
</beans> 


这 里 使 用 <mvc:annotation-driven/> 标 签 来 配置 ， 另 外 使 用 <mvc:view-resolvers> 配 置 了 ViewResolver， 使 用 的 是 处 理 jsp 的 InternalResourceViewResolver， 并 配置 了 prefix 和 suffix。 


下 面 是 Controller: 


Package com.excelib.controller; 
// 省 略 了 imports 
@Controller 
Q@SessionAttributes ("articleId") 
public class FollowMeController { 
Private final Log logger = LogFactory.getLog (FollowMeController.class); 
private final String[] sensitiveWords = new String[]{"kl", "s2"}; 
@ModelAttribute ("comment") 
public String replaceSensitiveWords (String comment) throws IOException { 
if(comment != null){ 
logger.info ("原始 comment: "+comment); 
for (String sw : sensitiveWords) 
Comment = comment.replaceAll (sw, ""); 
logger.info (" 去 敏感 词 后 comment: " + comment); 


return comment; 
} 
@RequestMapping (value={"/articles/{articleId} /comment"}) 
public String doComment (GPathVariable String articlelId,RedirectAttributes attributes, Model model) throws Exception { 
attributes.addFlashAttribute ("comment", model.asMap() .get ("comment")); 
model .addAttribute ("articleId"，articleId) 7 
// 此 处 将 评论 内 容 保存 到 数据 库 
return "redirect:/showArticle"; 
: 
@RequestMapping (value={"/showArticle"}, method= {RequestMethod.GET}) 
public String showArticle (Model model, SessionStatus sessionStatus) throws Exception { 
String articleId = (String)model .asMap() .get ("articleId"); 
model .addAttribute ("articleTitle", articleTd+" 号 文章 标题 ") ; 
model .addAttribute ("article"，articleId+" 号 文章 内 容 ") 7 
sessionStatus .SetComplete () 7 
return "article"; 


去 除 敏感 词 是 在 注释 了 @ModelAttribute 的 replaceSensitiveWords 方 法 执行 中 ， 这 里 使 用 了 final 的 String 数 组 属性 sensitiveWords 来 保存 敏感 词 ， 以 “k1” 和 “s2” 为 例 ， 实 际 使 用 时 可 以 保存 到 数 
据 库 并 读 取 到 缓存 中 。 


最 后 是 创建 显示 页 面 ， 在 /WEB-INF/views/jsp/ 目 录 下 新 建 一 个 article.jsp 文 件 ， 内 容 如 下 : 


<%@ page contentType="text/html;charset=UTF-8" language="java" %> 
<html> 
<head> 
<title>${articleTitle}</title> 
</head> 
<body> 
${articleTitle} 
<hr width="10%" /> 
${article} 
<br/><br/> 
评论 <br/> 
$ {comment} 
</body> 
</html> 


这 里 的 显示 页 面 只 是 简单 地 输出 了 文章 标题 、 文 章 内 容 和 评论 。 


程序 准备 好 了 ， 下 面 开始 分 析 。 先 大 致 分 析 一 下 启动 过 程 ， 然 后 详细 分 析 请 求 的 处 理 过 程 


因为 在 web.xml 文 件 中 给 Spring MVC 的 Servlet 配 置 了 load-on-startup， 所 以 程序 启动 时 会 初始 化 Spring MVC， 在 HttpServletBean 中 将 配置 的 contextConfigLocation 属 性 设置 到 Servlet 中 ， 然 后 
ei pe Notre DispatcherServlet 根 据 contextConfigLocation 配 置 的 classpath 下 的 followMe.xml 文 件 初始 化 了 Spring MVC 中 的 组 件 。 这 就 是 Spring MVC 容 
器 创建 的 过 程 ， 下 面 来 分 析 具 体 处 理 请 求 的 过 


评论 正常 应 该 使 用 表单 的 Post 请 求 来 操作 ， 这 里 为 了 方便 ， 直 接 使 有 
k1k1”) 。 


了 Get 请 求 ， 这 并 不 影响 我 们 对 请 求 的 跟踪 。 启动 程序 后 在 浏览 器 中 输入 下 面 的 网 址 (代表 id 为 67 的 文章 ,评论 是 “好 s2 赞 


http://localhost:8080/articles/67/comment?comment= 好 s2 鞠 kl1k1l 


1) 请 求 发 送 到 服务 器 后 ， 服 务 器 程序 就 会 分 配 一 个 Socket 线 程 来 跟 它 连接 ， 接 着 创建 出 request 和 response， 然 后 交 给 对 应 的 Servlet 处 理 ， 这 样 请 求 就 从 Servlet 容 器 传递 到 了 Servlet (Servlet 容 
器 ) 。 


2) 在 Servlet 中 请 求 首先 会 被 HttpServlet 处 理 ， 在 HttpServlet 的 service 方 法 中 将 Servlet-Request 和 ServletResponse 转 换 为 HttpServletRequest 和 HttpServletResponse， 并 调用 转换 为 后 Request 和 
Response 的 service 方 法 (Java 的 HttpServlet) 。 


3) 接 下 来 请 求 就 到 了 Spring MVC,， 在 Spring MVC 中 首先 由 FrameworkServlet 的 service 方 法 进行 处 理 ， 这 里 service 方 法 又 会 将 请 求 交 给 HttpServlet 的 service 方 法 处 理 (Framework-Servlet) 。 


4) 在 HttpServlet 的 service 方 法 中 会 根据 请 求 类 型 将 请 求 传递 到 doGet 方 法 (Java 的 HttpServlet) 。 


5) doGet 方 法 在 Spring MVC 的 FrameworkServlet 中 ， 它 又 将 传递 到 了 processRequest 方 法 ， 然 后 在 processRequest 方 法 中 将 当前 请 求 的 LocaleContext 和 RequestAttributes 设 置 到 
LocaleContextHolder 和 RequestContextHolder 后 将 请 求 传递 到 了 doService 方 法 ，doService 方 法 在 DispatcherServlet 里 实现 (FrameworkServlet) 。 


6) DispatcherServlet 的 doService 方 法 将 webApplicationContext、localeResolver、theme-Resolver、themeSource、outputFlashMap 和 flashMapManager 设 置 到 了 request 的 属性 中 ， 然 后 将 
请 求 传递 到 了 doDispatch 方 法 中 (DispatcherServlet) 。 


7) DispatcherServlet 的 doDispatch 中 首先 调用 checkMultipart 方 法 检查 是 不 是 上 传 请 求 ， 然 后 调 


getHandler 方 法 获取 到 Handler (DispatcherServlet) 。 


8) getHandler 方 法 获取 Handler 的 过 程 会 遍历 容器 中 所 有 的 HandlerMapping，<mvc: annotation-driven/> 标 签 配置 的 HandlerMapping 是 RequestMappingHandlerMapping 和 BeanName- 
UrlHandlerMapping， 在 用 RequestMappingHandlerMapping 匹 配 时 我 们 的 请 求 会 和 其 初始 化 时 读 取 到 定义 的 @RequestMapping (value={"/articles/{articleldj/comment"}) 所 注释 的 内 容 相 匹配 ， 
然后 根据 这 个 条 件 找到 定义 的 处 理 器 方法 doComment (RequestMappingHandlerMapping) 。 


9) 找到 处 理 器 后 调用 RequestMappinglnfoHandlerMapping 里 的 handleMatch 方 法 会 将 匹配 到 的 Pattern (/articles/{articleldycomment) 和 articleld 这 个 PathVariable 设 置 到 了 request 的 属性 中 


(RequestMappinglnfoHandlerMapping) 。 


10) 找到 Handler 后 返回 DispatcherServlet 的 doDispatch 方 法 中 ， 然 后 调 
的 所 有 HandlerAdapter， 然 后 分 别 调用 它们 的 supports 方 法 进行 检查 ， 检 查 的 
RequestMappingHandlerAdapter、HttpRequestHandlerAdapter 和 SimpleControllerHandlerAdapter， 最 


11) DispatcherServlet 的 doDispatch 方 法 中 检查 到 是 Get 请 求 ， 然 后 检查 是 否 可 以 使 用 缓存 ， 因 为 Reques 
调用 了 Handlerlnterceptor 的 preHandle 方 法 ， 这 里 没有 配置 Handlerlnterceptor， 这 一 步 就 不 管 了 ， 接 下 来 


12) RequestMappingHandlerAdapter 首 先 在 其 : 


应 的 SessionAttributesHandler， 并 判断 出 注释 有 @SessionAttributes， 进 而 调 上 有 


(RequestMappingHandlerAdapter) 。 


getHandler-Adapter 方 法 根据 Handler 查 找 HandlerAdapter， 也 就 是 根据 工 . 
方法 通常 是 看 Handler 的 类 型 是 否 支持 ，<mvc:annotation-driven/> 标 签 配置 


找 使 用 工 


的 人 。 查 找 的 方式 也 是 遍历 配 


后 找到 RequestMappingHandlerAdapter (Dispatc 


父 类 的 handle 方 法 中 直接 将 请 求 传递 到 了 它 的 handlelnternal 方 法 ，handlelnternal 方 法 首先 调 
checkAndPrepare 方 法 禁止 了 Response 的 缓存 ， 然 后 将 请 求 传递 型 


Hand 


erAdapter 是 


herServlet) 。 


tMappingHandlerAdapter 的 getLastModified 方 法 直接 返回 -1， 所 以 不 会 使 用 缓存 ， 接 着 
RequestMappingHandlerAdapter 使 用 Handler 处 理 请 求 (DispatcherServlet) 。 


getSessionAttributesHandler 初 始 化 了 本 处 理 器 对 
了 invokeHandleMethod 方 法 


13) RequestMappingHandlerAdapter 的 invokeHandleMethod 方 法 中 首先 创建 了 WebData-Binder-Factory、ModelFactory 和 ServletlnvocableHandlerMethod，ModelFactory 创 建 过 程 中 会 找 
到 定义 的 注释 了 @ModelAttribute 的 replaceSensitiveWords 方 法 (RequestMappingHandlerAdapter) 。 


14) 接着 创建 ModelAndViewContainer， 并 调 


ModelFactory 的 initModel 方 法 给 Model 设 置 参 数 ， 这 和 旦 


有 会 调用 了 定义 的 replaceSensitiveWords 方 法 ,， 调 


前 会 使 


RequestParamMethodArgumentResolver 解 析出 “comment” 参 数 的 值 (“好 s2 赞 k1k1”) 并 设置 给 replaceSensitiveWords 方 法 ， 方 法 处 理 完 (去 除 敏感 词 ) 
@ModelAttribute 注 释 中 的 “comment” 作 为 name， 去 除 敏感 词 后 的 评论 内 容 作为 value 设 置 到 Model 中 (ModelFactory) 。 


15) 接 下 来 调用 ServletlnvocableHandlerMethod 的 invokeAndHandle 方 法 实际 执行 处 理 。 首 先 在 父 类 InvocableHandlerMethod 的 invokeForRequest 方 法 中 调 


户 
所 ,，M 


odelFactory 将 其 使 用 


了 getMethodArgument-Values 


方法 来 解析 参数 ，@PathVariable、RedirectAttributes、Model 三 个 参数 分 别 使 用 PathVariable-MethodArgumentResolver、RedirectAttributesMethodArgumentResolver 和 | 
属性 中 的 值 (67) ， 第 二 个 会 新 建 一 个 RedirectAttributesModelMap 然 后 设置 到 
ner 中 的 Model， 这 时 的 Model 中 已 经 保存 了 前 面 去 敏感 词 后 的 comment 参 数 (InvocableHandlerMethod) 。 


ModelMethodProcessor 三 个 参数 解析 器 来 解析 ， 第 一 个 返回 在 HandlerMapping 中 (第 9 步 ) 设置 到 request 


mavContainer 中 并 返回 ， 第 三 个 直接 返回 mavContai 


16) 接 下 来 调用 InvocableHandlerMethod 的 dol 


将 “articleld” 设 置 到 Model 中 ， 因 为 它 在 @SessionAttributes 中 进行 了 设置 ， 


nvoke 方 法 处 理 请 求 ， 这 里 实际 调用 了 我 们 编写 的 doComment 方 法 ， 其 中 将 “comment” 设 置 到 RedirectAttributes 中 ， 通 过 FlashMap 传 递 , 


ServletlnvocableHandlerMethod (定义 的 FollowMeController) 。 


17) ServletlnvocableHandlerMethod 使 用 HandlerMethodReturnValueHandler 处 理 返回 值 ， 因 为 返 


回 


的 是 String， 所 以 使 用 的 是 ViewNameMethodReturnValueHandler， 它 首先 将 返 区 


所 以 会 保存 到 SessionAttributes 中 ， 处 理 完 后 返回 “redirect:/showArticle”， 将 请 求 返回 到 


值 "redirect:/showArticle" 设 置 到 mavContainer 的 view 里 ， 然 后 将 mavContainer 中 的 redirect 标 志 redirectModelScenario 设 置 为 了 true， 这 样 ServletInvocableHandlerMethod 就 处 理 完了 ， 接 着 将 请 


求 返回 RequestMappingHandlerAdapter (Servletln 


vocableHandlerMethod) 。 


18) RequestMappingHandlerAdapter 调 用 getModelAndView 方 法 对 返回 值 进一步 处 理 ， 首 先 使 用 ModelFactory 的 updateMode| 方 法 处 理 @sessionAttributes 注 释 ， 将 其 中 的 "articleld" 参 数 从 


Model 中 取出 并 使 用 sessionAttributesHandler 保 存 ; 


然后 使 用 mavContainer 中 的 Model 和 View 创 建 ModelAndView; 最 后 检查 到 Model 是 RedirectAttributes 类 型 ( 因 
且 设 置 了 RedirectAttributes 属 性 ， 所 以 mavContainer 中 getModel 会 返回 RedirectAttributes 类 型 的 Model) ， 这 时 会 将 之 前 保存 到 RedirectAttributes 中 的 “comment” 参 数 设置 到 outputFlashMap， 


这 样 RequestMappingHandlerAdapter 的 处 理 就 完成 了 ， 请 求 返回 DispatcherServlet 中 (RequestMappingH 


19) DispatcherServlet 在 doDispatch 方 法 中 首先 检查 返回 的 View 是 否 为 空 ， 如 果 为 空 使 


法 ， 这 里 这 两 项 都 不 需要 处 理 。 接 下 来 将 请 求 传递 到 processDispatchResult 方 法 (DispatcherServlet) 。 


20) DispatcherServlet 的 processDispatchResult 方 法 中 首先 判断 是 否 有 异常 ， 这 里 没有 风 
程 使 用 到 了 ViewResolver， 这 里 使 用 的 是 我 们 配置 的 InternalResourceViewResolver， 


然后 调用 resolveViewName 方 法 解析 出 View， 解 析 过 


RequestToViewNameTranslator 查 找 默 认 View， 然 


andlerAdapter) 。 


为 我 们 返回 的 是 redirect 视 | 


”站 


区 


后 执行 Handlerlnterceptor 的 applyPost-Handle 方 


需要 处 理 ， 然 后 调用 render 方 法 进行 页 面 的 泻 染 。render 方 法 中 首先 使 


localeResolver 解 析出 Locale; 


中 ， 它 检查 到 是 redirect 的 返回 值 ， 所 以 创建 了 RedirectView 类 型 的 View; 然后 调用 View 的 render 方 法 泻 染 输 出 (DispatcherServlet) 。 


体 处 理 方法 在 UrlBasedViewResolver 的 createView 方 法 


21) RedirectView 的 render 方 法 在 父 类 AbstractView 中 定义 ， 其 中 调用 了 RedirectView 的 renderMergedOutputModel 方 法 ，renderMergedOutputModeI 方 法 中 将 request 属 性 中 保存 的 


outputFlashMap 和 FlashMapManager 取 出 ， 使 用 FlashMapManager 将 outputF 


DispatcherServlet 的 processDispatchResult 方 法 (RedirectView) 。 


22) DispatcherServlet 的 processDispatchResult 方 法 接着 调用 Handler 的 triggerAfterComp-letion 方 法 ， 


Servlet (DispatcherServlet) 。 


23) 在 Fr ameworkServlet 的 processRequest 方 法 中 将 原来 的 


息 ， 最 后 将 请 求 返 回 给 Servlet 容 器 (FrameworkServl 


这 样 一 个 完整 的 请 求 就 处 理 完了 。 


et) 。 


Redirect 后 的 请 求 处 理 过 程 大 致 和 前 面 的 过 程 差不多 ， 主 要 有 以 下 不 同 : 


1) 在 上 述 第 6 步 中 DispatcherServlet 的 doService 方 法 会 使 


flashMapManager 将 之 前 保存 的 FlashMap 取 


ashMap 保 存 到 了 Session 中 ， 然 后 调用 sendRedirect 方 法 使 用 response 的 sendRedirect 方 法 将 请 求 发 出 ， 然 后 请 求 返 


回 


进而 调用 拦截 器 的 afterCompletion 方 法 ， 然 后 将 请 求 返回 


2) 在 上 述 第 14 步 中 ModelFactory 的 initMode| 方 法 会 将 之 前 保存 在 SessionAttributes 中 的 “articleld” 参 数 设置 到 Model 中 ; 


到 Framework- 


保存 到 request 的 “INPUT_FLASH_MAP_ATTRIBUTE” 


LocaleContext 和 RequestAttributes 恢 复 到 LocaleContextHolder 和 RequestContextHolder 中 ， 并 发 出 ServletRequestHandledEvent 消 


属性 中 ; 


3) 在 上 述 第 15 步 中 参数 解析 器 使 用 的 是 ModelMethodProcessor 和 SessionStatusMethodArgumentResolver， 


4) 在 上 述 第 18 步 中 ModelFactory 的 updateMode| 方 法 会 在 判断 mavContainer 中 session-Status 的 状态 后 将 SessionAttributes 清 空 ; 


它们 都 是 直接 从 mavContainer 中 获取 的 ; 


5) 在 上 述 第 20、21 步 中 由 于 本 次 返回 值 不 是 redirect 类 型 所 以 InternalResourceView-Resolver 解 析出 的 不 是 RedirectView 而 是 jsp 类 型 的 InternalResourceView， 对 应 的 模板 是 /WEB- 
INF/views/jsp/article.jsp。 


最 后 浏览 器 的 显示 结果 如 图 21-2 所 示 。 


可 以 看 到 评论 中 的 “k1” 


一 一 一 


67 号 允 章 标题 


67 号 区 章 内 容 


评论 
好 狗 


图 21-2 


第 22 章 异步 请 求 


请 求 处 理 结果 截图 


localhost8080/showArticle 


“s2” 敏 感 词 已 经 去 除 掉 。 我 们 对 请 求 的 跟踪 就 到 这 里 ， 建 议 大 家 自己 把 环境 搭建 起 来 然后 一 步 一 步 跟着 走 一 遍 ， 自 己 实际 跟踪 一 遍 印 象 会 更 深刻 。 


Servlet3.0 规 范 新 增 了 对 异步 请 求 的 支持 ，Spring MVC 也 在 此 基础 上 对 异步 请 求 提供 了 方便 。 异 步 请 求 是 在 处 理 比较 耗 时 的 业务 时 先 将 request 返 回 ， 然 后 另 起 线 程 处 理 耗 时 的 业务 ， 处 理 完 后 再 返回 


给 用 户 。 


异步 请 求 可 以 给 我 们 带 来 很 多 方便 ， 最 直接 的 用 法 就 是 处 理 耗 时 的 业务 ， 比 如 ， 需 要 查询 数据 库 、 需 要 调 


处 理 完成 后 再 将 结果 返回 给 


能 也 是 这 种 技术 。 甚 至 更 进一步 的 使 用 方式 是 在 浏览 器 上 做 即时 通信 的 程序 ! 


别 的 服务 器 来 处 理 等 情况 下 可 以 先 将 请 求 返回 给 客户 端 ， 然 后 启用 新 线程 处 理 耗 时 业务 ， 等 
户 。 稍 微 扩 展 一 下 还 可 以 实现 订阅 者 模式 的 消息 订阅 功能 ， 比 如 ， 当 有 异常 情况 发 生 时 可 以 主动 将 相关 信息 发 给 运 维 人 员 ， 还 有 现在 很 多 邮箱 系统 中 收 到 新 邮件 的 自动 提示 功 


HTTP 协 议 是 单 向 的 ， 只 能 客户 端 自己 拉 不 能 服务 器 主动 推 ，Servlet 对 异步 请 求 的 支持 并 没有 修改 HTTP 协 议 ， 而 是 对 Http 的 巧妙 利用 。 异 步 请 求 的 核心 原理 主要 分 为 两 大 类 ， 一 类 是 轮 询 ， 另 一 类 是 长 


连接 。 轮 询 就 是 定时 自动 发 起 请 求 检查 有 没有 需要 返回 的 数 
客户 端 数据 。Servlet 对 异步 请 求 的 支持 其 实 采用 的 是 长 连接 的 方式 ， 也 就 是 说 ， 异 步 请 求 中 在 原始 的 请 求 返回 


居 ， 这 种 方式 对 资源 的 浪费 是 比较 大 的 ;长 连接 的 原理 是 在 客 


在 异步 请 求全 部 处 理 完 之 后 才 会 关闭 连接 。 


有 2 有 2 和 


Servlet3.0 对 异步 请 求 的 支持 


在 Servlet3.0 规 范 中 使 用 异步 处 理 请 求 非常 简单 ， 只 需要 在 请 求 处 理 过程 中 调用 request 的 startAsyn<c 方 法 即 可 ， 其 返回 值 是 AsyncContext 类 型 。 


AsyncContext 在 异步 请 求 中 充当 着 非常 重要 的 角色 ， 可 以 称 为 异步 请 求 上 下 文 也 可 以 称 为 异步 请 求 容 器 ， 无 论 叫 什么 其 实 就 是 个 名 字 ， 它 的 作 
的 ServletContext。 异 步 请 求 主要 是 使 用 AsyncContext 进 行 操作 ， 它 是 在 请 求 处 理 的 过 程 中 调用 Request 的 startAsyn<c 方 法 返回 的 ， 需 


AsyncContext 接 口 定义 如 下 : 


户 端 发 起 请 求 ， 服 务 端 处 理 并 返回 后 并 不 结束 连接 ， 这 样 就 可 以 在 后 面 再 次 返回 给 
的 时 候 并 没有 关闭 连接 ， 关 闭 的 只 是 处 理 请 求 的 那个 线程 (一般 是 回收 的 线程 池 里 了 ) ， 只 有 


是 保存 与 异步 请 求 相 关 的 所 有 信息 ， 类 似 于 Servlet 中 


注意 的 是 多 次 调用 startAsync 方 法 返回 的 是 同一 个 AsyncContext。 


Package javax.servlet; 
public interface AsyncContext { 


static final String ASYNC REQUEST URI = "javax。 servlet .async.request_Uri" 
static final String ASYNC CONTEXT PATH = "javax.servlet.async. ContexE path 
static final String ASYNC PATH INFO = "javax。 servlet .async.path info"; 

static final String ASYNC SERVLET PATH = "javax. servlet .async.servlet path"; 
static final String ASYNC QUERY STRING = "javax.servlet.async.query string"; 
public ServletRequest getRequest (); 

Public ServletResponse getResponse(); 

public boolean hasOriginalRequestAndResponse(); 

public void dispatch(); 

public void dispatch (String path); 

public void dispatch (ServletContext context, String path); 

public void complete(); 

public void start (Runnable run); 


Public void addListener (AsyncListener listener); 

public void addListener (AsyncListener listener, 
ServletRequest servletRequest, 
ServletResponse servletResponse); 

public <T extends AsyncListener> T createListener (Class<T> clazz) 

throws ServletException; 
public void setTimeout (long timeout); 
public long getTimeout (); 


其 中 ，getResponse 方 法 上 


得 非常 多 ， 它 可 以 获取 到 response， 然 后 就 可 以 对 response 进 行 各 种 操作 了 ; dispatch 方 法 


于 将 请 求 发 送 到 一 个 新 地 址 ， 有 三 个 重 载 实现 方法 ， 其 中 没有 参数 dispatch 方 


法 的 会 发 送 到 request 原 来 的 地 址 (如 果 有 forward 则 使 用 forward 后 的 最 后 一 个 地 址 ) ， 一 个 path 参 数 的 dispatch 方 法 直接 将 path 作 为 地 址 ， 两 个 参数 的 dispatch 方 法 可 以 发 送 给 别 的 应 用 指定 的 地 址 ; 


complete 方 法 用 于 通知 容器 请 求 已 经 处 理 完 了 ; start 方 法 


于 启动 实际 处 理 线程 ， 不 过 也 可 以 自己 创建 线程 在 其 中 使 


于 添加 监听 


AsyncContext 保 存 的 信息 (如 response) 进行 处 理 ; addListener 


器 ; setTimeout 方 法 用 于 修改 超时 时 间 ， 因 为 异步 请 求 一 般 耗 时 比较 长 ， 而 正常 的 请 求 设置 的 有 效 时 长 一 般 比 较 短 ， 所 以 在 异步 请 求 中 很 多 时 候 都 需要 修改 超时 的 时 间 。 


| 


Servlet 3.0 处 理 异 步 请 求实 例 


使 


Servlet 3.0 处 理 异步 请 求 


处 理 异步 请 求 。 


想 使 


要 三 步 : @ 配 置 Servlet 时 将 async-supported 设 置 为 true; @ 在 Servlet 处 理 方法 中 调 


Request 的 startAsync 方 法 启动 异步 处 理 ; @ 使 


Servlet 3.0 异 步 请 求 的 功能 需要 在 配置 Servlet 时 将 async-supported 设 置 为 true， 比 如 ， 配 置 一 个 叫 WorkServlet 的 可 以 处 理 异 步 请 求 的 Servlet。 


<!-- web.xml --> 
<servlet> 


<servlet-name>WorkServlet</servlet-name> 
<servlet-class>com.excelib.servlet .WorkServlet</servlet-class> 
<async-supported>true</async-supported> 


</servlet> 
<servlet-mapping> 


<servlet-name>WorkServlet</servlet-name> 
<url-pattern>/work</url-pattern> 


</servlet-mapping> 


然后 新 建 一 个 叫 WorkServlet 的 Servlet， 代 码 如 下 : 


package com.excelib.servlet; 
// 省 略 了 jimports 
public class WorkServlet extends HttpServlet { 


private static final long serialVersionUID = 1L7 
QOverride 
protected void doGet (HttpServletRequest req, HttpServletResponse resp) 
throws ServletException, IOException { 
this .doPost (req, resp); 


QOverride 
protected void doPost (HttpServletRequest req, HttpServletResponse res) 
throws ServletException, IOException { 
// 设置 contentType、 关 闭 缓存 
res.setContentType ("text/plain;charset=UTF-8"); 
res.setHeader ("Cache-Control", "private"); 
res.setHeader ("Prar no-cache"); 
// 原始 请 求 可 以 做 一 些 简单 业务 的 处 理 
final PrintWriter writer = res.getWriter(); 
writer.println ("老板 检查 当前 需要 做 的 工作 "); 
writer.flush(); 
// jobs 表 示 需 要 做 的 工作 ， 使 用 循环 模拟 初始 化 
List<String> jobs = new ArrayList<>(); 
for (int i=0;i<10;i++){ 
jobs.add ("job"+i); 


} 
// 使 用 request 的 startAsync 方 法 开启 异步 处 理 
final AsyncContext ac = req.startAsync (); 
// 具体 处 理 请 求 ， 内 部 处 理 启用 了 新 线程 ， 不 会 阻塞 当前 线程 
doWork (ac, jobs); 
writer.println ("老板 布置 完工 作 就 走 了 "); 
writer.flush(); 
} 
Private void doWork (AsyncContext ac, List<String> jobs){ 
// 设 置 超时 时 间 1 小 时 
ac.setTimeout (1*60*60*1000L); 
// 使 用 新 线程 具体 处 理 请 求 
ac.start (new Runnable() { 
QOverride 
public void run() { 
try { 
// 从 AsyncContext 获 取 到 Response， 进 而 获取 到 Writer 
PrintWriter w = ac.getResponse () .getWriter (); 
for (String job:jobs){ 
Ww.printin ("ww+jobt"\" 请 求 处 理 中 …") ; 
Thread.sleep (1 * 1000L); 
w.flush(); 


} 
// 发 出 请 求 处 理 完成 通知 
ac.complete () 7 

} catch (Exception e) { 
e.printstackTrace () 7 


这 里 的 异步 处 理 过 程 是 在 doWork 方 法 中 ， 它 使 
startAsync 和 doWork 外 都 是 正常 的 操作 ， 而 且 都 有 注释 ， 就 不 解析 了 。 当 调 


redq.startAsync( 返 回 的 AsyncContext 来 处 理 的 请 求 ， 处 理 完成 后 调用 complete 方 法 发 出 完成 通知 告诉 容器 请 求 已 经 处 理 完 。doPost 中 除了 


请 求 时 ， 返 回 页 面 结果 如 


22-1 所 示 。 


第 2 步 中 返回 的 AsyncContext 


7 "pe 8080/work 


老板 检查 当前 需要 做 的 工作 
老板 布置 完工 作 就 走 了 
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22-1 ”异步 处 理 返回 页 面 截图 


一 个 通过 异步 请 求 完 成 工作 的 示例 程序 就 写 完了 。 


22.1.2 ”异步 请 求 监听 器 AsyncListener 


上 面 的 程序 已 经 可 以 完成 工作 了 ， 不 过 还 不 够 完善 。 老 板 这 个 职业 是 需要 思考 宏观 问题 的 ， 它 需要 宏观 的 数据 ， 所 以 在 干 完 活 后 最 好 给 领导 汇报 一 下 什么 时 候 干 完 的 、 干 的 怎么 样 、 有 没有 出 什么 问题 
等 综合 性 的 数据 ， 不 过 这 些 事情 按照 分 工 并 不 应 该 由 实际 干 活 的 人 来 做 ， 如 果 非 让 它们 做 就 可 能 会 影响 效率 ， 而 且 它 们 汇报 的 数据 也 有 可 能 不 真实 ， 所 以 老板 应 该 找 专人 来 做 这 件 事 ， 这 就 有 了 二 线 人 员 。 
在 Servlet 异 步 请 求 中 干 这 个 活 的 二 线 人 员 就 是 AsyncListener 监 听 器 ，AsyncListener 定 义 如 下 : 


package javax.servlet; 

import java.io.IOException; 

import java.util.EventListener; 

public interface AsyncListener extends EventListener { 
public void onComplete (AsyncEvent event) throws IOException; 
public void onTimeout (AsyncEvent event) throws IOException; 
public void onError (AsyncEvent event) throws IOException; 
public void onSstartAsync (AsyncEvent event) throws IOException; 

} 


onComplete 方 法 在 请 求 处 理 完 成 后 调用 ，onTimeout 方 法 在 超时 后 调用 ，onError 方 法 在 出 错时 调用 ，onStartAsync 方 法 在 Request 调 用 startAsync 方 法 启动 异步 处 理 时 调用 。 


里 需要 注意 的 是 只 有 在 调用 request.startAsync 前 将 监听 器 添加 到 AsyncContext， 监 听 器 的 onStartAsync 方 法 才 会 起 作用 ， 而 调用 startAsync 前 AsyncContext 还 不 存在 ， 所 以 第 一 次 调 
startAsync 是 不 会 被 监听 器 中 的 onStartAsync 方 法 捕获 的 ， 只 有 在 超时 后 又 重新 开始 的 情况 下 onStartAsync 方 法 才 会 起 作用 。 这 一 般 也 没有 什么 太 大 的 问题 ， 就 像 上 面 的 例子 中 开始 的 时 候 是 老板 安排 的 任 
务 ， 他 自己 当然 知道 ， 所 以 不 汇报 也 没关系 ， 不 过 如 果 到 了 时 间 节 点 任务 没完 成 又 重新 开始 了 那 还 是 要 汇报 的 。 


我 们 给 前 面 的 WorkServlet 添 加 两 个 AsyncListener 监 听 器 BossListener 和 LeaderListener， 一 个 用 来 给 老板 汇报 ， 另 一 个 用 来 给 项 目 负责 人 汇报 ， 它 们 都 是 定义 在 WorkServlet 中 的 私有 类 ， 而 且 代 码 也 
都 一 样 ， 其 中 BossListener 的 代码 如 下 : 


// com.excelib.servlet .WorkServlet 
private class BossListener implements AsyncListener { 
final SimpleDateFormat formatter = new SimpleDateFormat ("yyyy-MM-dd HH:mm:ss"); 
QOverride 
public void onComplete (AsyncEvent event) throws IOException { 
System.out .println(" 在 " + formatter.format (new Date()) + "工作 处 理 完 成 "); 


¥ 
QOverride 
public void onError (AsyncEvent event) throws IOException { 
System.out .Println(" 在 " + formatter.format (new Date()) + "工作 处 理 出 错 ， 详 情 如 下 : \t" 
+event .getThrowable () .getMessage ()) 7 


} 
QOverride 


public void onstartAsync (AsyncEvent event) throws IOException { 
System.out .Println(" 在 " + formatter.format (new Date()) + "工作 处 理 开 始 ") 7 


} 
QOverride 


Public void onTimeout (AsyncEvent event) throws IOException { 
System.out .Println(" 在 " + formatter.format (new Date()) + "工作 处 理 超时 ") 


} 


然后 将 监听 器 注册 到 WorkServlet 中 ， 注 册 方 法 是 在 获取 到 AsyncContext 后 将 监听 器 添加 进去 ， 相 关 代码 如 下 : 


// com.excelib.servlet .WorkServlet 


final AsyncContext ac = 
// 添加 两 个 监听 器 


req.startAsync (); 


ac.addListener (new BossListener ()); 
ac.addListener (new LeaderListener(), reqg, res); 


// 具体 处 理 请 求 ， 内 部 处 理 启 
doWork (ac, jobs); 


用 了 新 线程 ， 不 会 阻塞 当前 线程 


这 样 就 将 两 个 监听 器 注册 完了 。 这 里 之 所 以 添加 了 两 个 监听 器 ， 是 要 告诉 大 家 一 个 AsyncContext 可 以 添加 多 个 监听 器 ， 而 且 有 两 个 重 载 的 添加 方法 。 在 监听 器 中 可 以 使 用 AsyncEvent 事 件 获 取 
Request、Response 以 及 在 有 异常 的 时 候 获 取 Throwable， 代 码 如 下 : 


event .getSuppliedRequest (); 
event .getSuppliedResponse (); 


event .getThrowable (); 


22.2 Spring MVC 中 的 异步 请 求 


Spring MVC 为 了 方便 使 用 异步 请 求 专门 提供 了 AsyncWebRequest 类 型 的 request， 并 | 


Spring MVC 将 异步 请 求 


目 提供 了 处 理 异 步 请 求 的 管理 器 WebAsyncManager 和 工具 WebAsyncUtils。 


分 为 了 Callable、WebAsyncTask、DeferredResult 和 Listenable-Future 四 种 类 型 。 前 两 种 是 一 类 ， 它 们 的 核心 是 Callable， 这 一 类 很 容易 理解 ， 因 为 大 家 对 Callable 应 该 都 


比较 熟悉 ; DeferredResult 类 可 能 不 是 很 容易 理解 ， 因 为 它 是 Spring MVC 自 
实 是 非常 简单 的 ; ListenableFuture 是 Spring MVC4.0 新 增 的 ， 它 在 Java 的 


己 定 义 的 类 型 ， 我 们 平时 可 能 没 使 用 过 ， 而 | 


了 AsyncRestTemplate 方 法 调 上 


别 的 资源 ， 并 返回 ListenableFuture 类 型 。 


本 章 先 分 析 Spring MVC 中 异步 请 求 使 用 到 的 组 件 ， 然 后 分 析 Spring MVC 是 怎么 使 


22.2.1 Spring MVC 中 异步 请 求 相关 组 件 


Future 基 础 上 增加 了 设置 回调 方法 的 功能 ,3 


目 相关 资料 也 不 多 ， 所 以 刚 接触 的 时 候 会 觉得 不 知道 从 哪里 入 手 ， 不 过 弄 明 白 后 其 


而 


在 处 理 器 中 调用 别 的 资源 (如 别 的 url) 的 情况 ，Spring MVC 专 门 提供 


这 些 组 件 处 理 异步 请 求 的 ， 最 后 再 分 别 对 每 一 类 返回 值 进行 介绍 。 


这 里 主要 分 析 AsyncWebRequest、WebAsyncManager 和 WebAsyncUtils 组 件 。WebAsyncManager 里 面 还 包含 了 一 些 别 的 组 件 ， 在 分 析 的 过 程 中 也 一 起 分 析 。 


AsyncWebRequest 


首先 来 看 AsyncWebRequest， 它 是 专门 用 来 处 理 异 步 请 求 的 request， 定 义 如 下 : 


Package org.springframework.web.context.request .async; 
import org.springframework.web.context.request.NativeWebRequest; 
public interface AsyncWebRequest extends NativeWebRequest { 
void setTimeout (Long timeout); 
void addTimeoutHandler (Runnable runnable); 
void addCompletionHandler (Runnable runnable); 


void startAsync () 7 


boolean isAsyncStarted(); 


void dispatch () 7 


boolean isAsyncComplete () 7 


其 中 ，addTimeoutHandler 方 法 和 addCompletionHandler 方 法 分 别 有 
isAsyncStarted 方 法 用 于 判断 是 否 启动 了 异步 处 理 ; isAsyncComplete 方 法 | 


于 添加 请 求 超时 和 请 求 处 理 完成 的 处 理 器 ， 


其 作 |F 


相当 了 


AsyncListener 监 听 器 中 的 onTimeout 和 onComplete 方 法 ; 


于 判断 异步 处 理 是 否 已 经 处 理 完了 。 别 的 方法 都 与 AsyncContext 中 的 同名 方法 作用 一 样 ， 就 不 一 一 解释 了 。 它 的 实现 类 有 两 


个 ， 一 个 是 NoSupportAsyncWebRequest， 另 一 个 是 StandardSservlet-AsyncWebRequest， 前 者 不 支持 异步 请 求 ， 所 以 在 Spring MVC 中 实际 用 作 异 步 请 求 的 request 是 
StandardServletAsyncWebRequest。 


StandardServletAsyncWebRequest 除 了 实现 了 AsyncWebRequest 接 口 ， 还 实现 了 AsyncListener 接 


口 ， 另 外 还 继承 了 ServletWebRequest， 代 码 如 下 : 


Package org.springframework.web.context .request.async; 


// 省 略 了 imports 


public class StandardServletAsyncWebRequest extends ServletWebRequest implements AsyncWebRequest, AsyncListener { 


private Long timeout; 
private AsyncContext 


asyncContext; 


private AtomicBoolean asyncCompleted = new AtomicBoolean (false); 

private final List<Runnable> timeoutHandlers = new ArrayList<Runnable>(); 

private final List<Runnable> completionHandlers = new ArrayList<Runnable>(); 

public StandardServletAsyncWebRequest (HttpServletRequest request, HttpServletResponse response) { 
super (request, response); 


3 


@Override 


public void setTimeout (Long timeout) { 


Assert.state (!isAsyncStarted(), 


this.timeout = timeout; 


} 


@Override 


public void addTimeoutHandler (Runnable timeoutHandler) { 
this.timeoutHandlers.add (timeoutHandler); 


} 


@Override 


public void addCompletionHandler (Runnable runnable) { 
this.completionHandlers.add (runnable); 


@Override 


public boolean isAsyncStarted() { 
return ((this.asyncContext != null) && getRequest () .1sAsyncStarted() ) 7 


} 


@Override 


public boolean isAsyncComplete() { 
return this.asyncCompleted.get (); 


让 


@Override 


public void startAsync() { 
Assert.state (getRequest () .isAsyncSupported(), 


"Cannot change the timeout with concurrent handling in progress"); 


"Async support must be enabled on a servlet and for all filters involVed"+ 
"in async request processing. This is done in Java code using the Servlet API "+ 
"or by adding \"<async-supported>true</async-supported>\" to servlet and " 十 
"filter declarations in web.xml."); 
Assert .state(!isAsyncComplete(), "Async processing has already completed"); 
if (isAsyncStarted()) { 
return; 
} 
this.asyncContext = getRequest () .startAsync (getRequest (), getResponse()); 
this.asyncContext .addListener (this); 
if (this.timeout != null) { 
this.asyncContext .setTimeout (this.timeout); 
} 
} 
@Override 
public void dispatch() { 
Assert .notNull (this.asyncContext, "Cannot dispatch without an AsyncContext"); 
this.asyncContext.dispatch (); 
} 
@Override 
public void onstartAsync (AsyncEvent event) throws IOException { 
@Override 
public void onError (AsyncEvent event) throws IOException { 
} 
@Override 
public void onTimeout (AsyncEvent event) throws IOException { 
for (Runnable handler : this.timeoutHandlers) { 
handler.run(); 
* 
} 
@Override 
public void onComplete (AsyncEvent event) throws IOException { 
for (Runnable handler : this.completionHandlers) { 
handler.run(); 
} 
this.asyncContext = null; 
this.asyncCompleted. set (true); 
} 


这 里 的 代码 比较 长 ， 不 过 很 容易 理解 ， 它 里 面 封 装 了 个 AsyncContext 类 型 的 属性 asyncContext， 在 startAsync 方 法 中 会 将 Request#startAsync 返 回 


它 来 完成 各 种 功能 。 


另外 ， 由 于 StandardServletAsyncWebRequest 实 现 了 AsyncListener 接 口 ， 所 以 它 自己 就 是 一 个 监听 器 ， 而 且 在 startAsync 方 法 中 在 创建 出 AsyncC 


方法 ， 这 样 在 使 用 时 只 需要 简单 地 将 需要 监听 超时 和 处 理 完成 的 监听 方法 添加 到 这 两 个 属性 中 就 可 以 了 。 


WebAsyncManager 
WebAsyncManager 是 Spring MVC 处 理 异 步 请 求 过 程 中 最 核心 的 类 ， 它 管理 着 整个 异步 处 理 的 过 程 。 


WebAsyncManager 中 最 重要 的 两 个 方法 是 startCallableProcessing 和 startDeferredResult-Processing， 这 两 个 方法 是 启动 异步 处 理 的 入 口 方 法 ， 
Request 设 置 相应 属性 (主要 包括 timeout、timeoutHandler 和 completionHandler) ; @ 在 相应 位 置 调用 相应 的 拦截 器 。 这 里 的 拦截 器 是 Spring MVC 


的 AsyncContext 设 置 给 它 ， 然 后 在 别 的 地 方 主要 使 


ontext 后 会 将 自己 作为 监听 器 添加 进去 。 监 听 器 实 
现 方 法 中 onStartAsync 方 法 和 onError 方 法 是 空 实现 ，onTimeout 方 法 和 onComplete 方 法 分 别 调用 了 封装 的 两 个 List<Runnable> 类 型 的 属性 timeoutHandlers 和 completionHandlers 所 保存 的 Runnable 


它们 一 共 做 了 三 件 事 : @ 启 动 异步 处 理 ; @ 给 


自己 定义 的 。 


startCallableProcessing 方 法 用 于 处 理 Callable 和 WebAsyncTask 类 型 的 异步 请 求 ， 使 用 的 拦截 器 类 型 是 CallableProcessinglnterceptor， 拦 截 器 封装 在 CallablelnterceptorChain 类 型 的 拦截 器 链 中 


统一 调用 。 


startDeferredResultProcessing 方 法 用 于 处 理 DeferredResult 和 ListenableFuture 类 型 的 异步 请 求 ， 使 用 的 拦截 器 是 DeferredResultProcessinglnterceptor 拦 截 器 ， 拦 截 器 封装 在 Deferred- 


ResultlnterceptorChain 类 型 的 拦截 器 链 中 统一 调用 。 


这 两 个 拦截 器 的 定义 如 下 : 


Package org.springframework.web.context.request.async; 
import java.util.concurrent.Callable; 
import org.springframework.core.task.AsyncTaskExecutor; 
import org.springframework.web.context.request.NativeWebRequest; 
public interface CallableProcessingInterceptor { 

static final Object RESULT NONE = new Object () 7 

static final Object RESPONSE HANDLED = new Object (); 
<T> void beforeConcurrentHandling (NativeWebRequest request, Callable<T> task) throws Exception; 
<T> void preProcess (NativeWebRequest request, Callable<T> task) throws Exception; 
<T> void postProcess (NativeWebRequest request, Callable<T> task, Object concurrentResult) throws Exception; 
<T> Object handleTimeout (NativeWebRequest request, Callable<T> task) throws Exception; 
<T> void afterCompletion (NativeWebRequest request, Callable<T> task) throws Exception; 
} 
Package org.springframework.web.context.request.async; 
import org.springframework.web.context.request.NativeWebRequest; 
public interface DeferredResultProcessingInterceptor { 
<T> void beforeConcurrentHandling (NativeWebRequest request, DeferredResult<T> deferredResult) throws Exception; 
<T> void preProcess (NativeWebRequest request, DeferredResult<T> deferredResult) throws Exception; 
<T> void postProcess (NativeWebRequest request, DeferredResult<T> deferredResult, Object concurrentResult) throws Exception; 
<T> boolean handleTimeout (NativeWebRequest request, DeferredResult<T> deferredResult) throws Exception; 
<T> void afterCompletion (NativeWebRequest request, DeferredResult<T> deferredResult) throws Exception; 
} 


拦截 器 的 作用 就 是 在 不 同 的 时 间 点 通过 执行 相应 的 方法 来 做 一 些 额外 的 事情 ， 所 以 要 学 习 一 种 拦截 器 主要 就 是 要 理解 它 里 边 的 各 个 方法 执行 的 时 间 点 。 这 两 拦截 器 都 定义 了 5 个 方法 ， 方 法 名 也 都 一 样 ， 


TT 


而 且 从 名 字 就 很 容易 理解 它们 执行 的 时 间 点 ， 就 不 分 别 解释 了 。 需 要 注意 的 是 ，beforeConcurrentHandling 方 法 是 在 并 发 处 理 前 执行 的 ， 也 就 是 会 在 主线 程 中 执行 ， 其 他 方法 都 在 


中 执行 。 


CallablelnterceptorChain 和 DeferredResultinterceptorChain 分 别 用 于 封装 两 个 Interceptor， 它 们 都 是 将 多 个 相应 的 拦截 器 封装 到 一 个 List 类 型 的 


体 处 理 请 求 的 子 线程 


属性 ， 然 后 在 相应 的 方法 中 调 


所 封装 的 


Interceptor 相 应 方法 进行 处 理 。 大 家 是 不 是 很 熟悉 ” 它 跟 前 面 多 次 使 用 的 XXXComposite 组 件 类 似 ， 也 是 责任 链 模式 。 不 过 和 XXXComposite 组 件 不 同 的 是 ， 这 里 的 方法 名 与 Interceptor 中 稍 有 区 别 ， 它 们 


的 对 应 关系 如 下 : 
“ applyBeforeConcurrentHandling: 对 应 Interceptor 中 的 beforeConcurrentHandling 方 法 。 
“ applyPreProcess: 对 应 Interceptor 中 的 preProcess 方 法 。 
“ applyPostProcess: 对 应 Interceptor 中 的 postProcess 方 法 。 
“triggerAfterTimeout: 对 应 Interceptor 中 的 afterTimeout 方 法 。 


“ triggerAfterCompletion: 对 应 Interceptor 中 的 afterCompletion 方 法 。 


理解 了 这 些 方法 就 知道 Interceptor 和 InterceptorChain 的 作用 了 ， 它 们 都 是 在 WebAsync-Manager 中 相应 位 置 调用 的 。 


主要 是 封装 Callable 方 


在 正式 分 析 WebAsyncManager 前 再 看 一 下 WebAsyncTask 类 ， 只 有 理解 了 这 个 类 才能 看 明白 WebAsyncManager 中 的 startCallableProcessing 方 法 。WebAsyncTask 的 作 
法 ， 并 且 提供 了 一 些 异 步调 用 相关 的 属性 ， 理 解 了 其 中 包含 的 属性 就 明白 这 个 类 了 ， 其 中 属性 定义 如 下 : 


// org.springframework.web.context.request .async.WebAsyncTask 
private final Callable<V> callable; 

private Long timeout; 

private AsyncTaskExecutor executor; 

private String executorName; 

Private BeanFactory beanFactory; 

private Callable<V> timeoutCallback; 

private Runnable completionCallback; 


callable 用 来 实际 处 理 请 求 ; timeout 用 来 设置 超时 时 间 ; executor 用 来 调用 callable; executorName 用 来 用 容器 中 注册 的 名 字 配 置 executor; beanFactory 用 于 根据 名 字 获 取 executor; 
timeoutCallback 和 completionCallback 分 别 用 于 执行 超时 和 请 求 处 理 完成 的 回调 。 


这 里 的 executor 可 以 直接 设置 到 WebAsyncTask 中 ， 也 可 以 使 用 注册 在 容器 中 的 名 字 来 设置 executorName 属 性 ， 如 果 是 使 用 名 字 来 设置 的 WebAsyncTask 的 getExecutor 方 法 会 从 beanFactory 中 根 
据 名 字 executorName 获 取 AsyncTaskExecutor， 代 码 如 下 : 


// org.springframework.web.context.request .async.WebAsyncTask 
public AsyncTaskExecutor getExecutor() { 
if (this.executor != null) { 
return this.executor; 
} 
else if (this.executorName != null) { 
Assert.state (this.beanFactory != null, “BeanFactory is required to look up an executor bean by name") 7 
return this.beanFactory.getBean (this.executorName, AsyncTaskExecutor.class); 
} 
else { 
return null; 


如 何在 Java 中 使 用 并 发 处 理 


并 发 处 理 是 通过 多 线程 完成 的 ， 在 Java 中 定义 一 个 多 线程 的 任务 可 以 通过 实现 Runnable 或 者 Callable 接 口 来 完成 ， 先 来 看 一 下 Runnable 接 口 ， 定 义 如 下 : 


package java.lang; 

public interface Runnable { 
public abstract void run(); 

} 


Runnable 里 只 有 一 个 ran 方法， 我 们 只 需要 将 需要 执行 的 代码 放 到 里 面 即 可 ， 它 的 执行 需要 新 建 一 个 线程 来 调用 ， 示 例如 下 : 


Runnable task = new Runnable() { 
QOverride 
public void run() { 
System.out .Println("do task"); 
} 
Es 
Thread thread = new Thread (task); 
thread. start (); 


这 里 新 建 了 task 的 Runnable 类 型 任务 ， 然 后 使 用 它 创 建 了 Thread 并 调用 start 方 法 执行 了 任务 。 需 要 说 明 的 是 ，Thread 本 身 也 继承 了 Runnable 接 口 ， 所 以 直接 使 用 Thread 来 创建 Runnable 类 型 的 任务 然后 执行 


比如 ， 上 面 的 代码 可 以 修改 为 : 


new Thread(){ 
QOverride 
public void run() { 
System.out.printin("do task"); 
} 
}.start (); 


这 样 一 名 代码 就 可 以 完成 了 。 


在 Javal.5 中 新 增 了 Callable 接 口 ， 定 义 如 下 : 


package java.util.concurrent; 
public interface Callable<V> { 

V calll() throws Exception; 
} 


Callable 里 面 是 cl 方法， 而 且 可 以 有 返回 值 还 可 以 处 理 异 常 。Callable 的 执行 需要 有 一 个 Executor 容 器 来 调用 ， 就 像 Runnable 任 务 需 要 Thread 来 调用 一 样 ， 而 且 Executor 也 可 以 调用 Runnable 类 型 的 任务 。 
Executor 调 用 后 会 返回 一 个 Future 类 型 的 返回 值 ， 我 们 可 以 调用 Futute 的 get 方 法 来 获取 Callable 中 call 方 法 的 返回 值 ， 不 过 这 个 方法 是 阻塞 的 ， 只 有 call 方 法 执行 完 后 才 会 返回 ， 示 例如 下 : 


ExecutorService executor = Executors .newCachedThreadPool () 7 
Callable callableTask = new Callable<String>() { 
QOverride 
public String call() throws Exception { 
Thread. sleep (1000); 
System.out .Println("do task"); 
return "ok"7 
} 
] 7 
Future<String> future = executor.submit (callableTask) 7 
System.out .Println("after submit task"); 
String result = future.get() 
System.out .Println("after future.get()") 7 
System.out .Println ("result="+result) 7 
executor .shutdown () 7 


这 里 定义 了 一 个 Callable 类 型 的 callableTask 任 务 ， 在 其 ca 方法 中 会 等 待 1 秒 然 后 输出 "do task" 并 返回 “ok”。Executor 调 用 submit 方 法 提交 任务 后 主 程序 输出 "after submit task"， 这 个 应 该 在 异步 任务 返回 之 
前 输出 ， 因 为 call 方 法 需要 等 待 1 秒 ， 输 出 "after submit task" 后 调用 fatute.get0 ， 这 时 主线 程 会 阻塞 ， 直 到 call 方 法 返回 ， 然 后 输出 "after futute.get0"， 最 后 输出 call 返 回 的 结果 "ok"， 程 序 运行 后 控制 台 打 印 如 下 : 


after submit task 
do task 

after future.get() 
result=ok 


下 面 来 看 WebAsyncManager， 首 先 介绍 它 里 面 的 几 个 重要 属性 : 


四 


“ timeoutCallableInterceptor: CallableProcessingInterceptor 类 型 ， 专 门 用 于 Callable 和 WebAsyncTask 类 型 超时 的 拦截 器 。 

* timeoutDeferredResultInterceptor: DeferredResultProcessing[nterceptor 类 型 ， 专 门 用 于 DeferredResult 和 ListenableFuture 类 型 超时 的 拦截 器 。 
callableInterceptors: Map 类 型 ， 用 于 所 有 Callable 和 WebAsyncTask 类 型 的 拦截 器 。 

“ deferredResultInterceptors: Mab 类 型 ， 用 于 所 有 DeferredResult 和 ListenableFuture 类 型 的 拦截 器 。 

' asyncWebRequest: 为 了 支持 异步 处 理 而 封装 的 request。 


“ taskExecutor: 用 于 执行 Callable 和 WebAsyncTask 类 型 处 理 ， 如 果 WebAsyncTask 中 没有 定义 executor 则 使 用 WebAsyncManager 中 的 taskExecutor。 


下 面 分 析 WebAsyncManager 里 最 核心 的 两 个 方法 startCallableProcessing 和 startDeferred-ResultProcessing， 这 两 个 方法 的 逻辑 基本 一 样 ， 选 择 
于 启动 Callable 和 WebAsyncTask 类 型 的 处 理 ， 代 码 如 下 : 


中 的 startCallableProcessing 来 分 析 ， 这 个 方法 


//org.springframework.web.context .request .asynct .WebAsyncManager 
public void startCallableProcessing (final WebAsyncTask<?> webAsyncTask, Objecthttp://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/15447/0EBPS 
Assert .notNull (webAsyncTask, "WebAsyncTask must not be nul1") 7 
Assert.state (this.asyncWebRequest != null, "AsyncWebRequest must not be nul1")7 
// 如 果 webAsyncTask 设 置 了 超时 时 间 ， 则 将 其 设置 到 request 
Long timeout = webAsyncTask.getTimeout (); 
if (timeout != null) { 
this.asyncWebRequest .setTimeout (timeout); 


} 
// 如 果 webAsyncTask 中 定义 了 executor 则 设置 到 taskExecutor 
AsyncTaskExecutor executor = webAsyncTask.getExecutor(); 
if (executor != null) { 

this.taskExecutor = executor; 


} 
// 创建 并 初始 化 拦截 器 临时 变量 ， 包 括 三 部 分 : 1) webRsyncTask 中 包含 的 拦截 器 ，2) 所 有 callableInterceptors 属 性 包含 的 拦截 器 ，3) 超时 拦截 器 
List<CallableProcessingInterceptor> interceptors = new ArrayList<CallableProcessingInterceptor> () 7 
interceptors.add (webAsyncTask.getInterceptor ()); 
interceptors.addAll (this.callableInterceptors.values ()); 
interceptors.add (timeoutCallableInterceptor); 
// 从 webAsyncTask 中 取出 真正 执行 请 求 的 Callable 任 务 
final Callable<?> callable = webAsyncTask.getCallable(); 
final CallableInterceptorChain interceptorChain = new CallableInterceptorChain (interceptors); 
// 给 request 添 加 超时 处 理 器 
this.asyncWebRequest.addTimeoutHandler (new Runnable() { 
QOverride 
public void run() { 
logger .debug ("Processing timeout"); 
Object result = interceptorChain.triggerAfterTimeout (asyncWebRequest, callable); 
if (result != CallableProcessingInterceptor.RESULT NONE) { 
setConcurrentResultAndDispatch (result); 
} 
} 


3 
// 给 request 添 加 请 求 处 理 完 成 的 处 理 器 
this.asyncWebRequest.addCompletionHandler (new Runnable() { 
Q@Override 
public void run() { 
interceptorChain.triggerAfterCompletion (asyncWebRequest, callable); 
. 


3 
// 执行 拦截 器 链 中 的 applyBeforeConcurrentHandling 方 法 ， 注 意 这 是 在 主线 程 中 执行 
interceptorChain.applyBeforeConcurrentHandling (this.asyncWebRequest, callable); 
// 启动 异步 处 理 
startAsyncProcessing (processingContext); 
// 使 用 taskExecutor 执 行 请 求 
this.taskExecutor.submit (new Runnable() { 
Q@Override 
public void run() { 
Object result = null; 
try { 
interceptorChain.applyPreProcess (asyncWebRequest, callable); 
result = callable.call (); 
} 
catch (Throwable ex) 1{ 
result = ex7 
} 
finally { 
result = interceptorChain.applyPostProcess (asyncWebRequest, callable, result); 


} 
// 设置 处 理 结果 并 发 送 请 求 
setConcurrentResultAndDispatch (result) 7 


通过 注释 可 以 看 到 startCallableProcessing 方 法 主要 做 了 5 件 事 : @ 将 webAsyncTask 中 相关 属性 取出 并 设置 到 对 应 的 地 方 ; @ 初 始 化 拦截 器 链 ; @ 给 asyncWebRequest 设 置 timeoutHandler 和 
completionHandler; @ 执 行 处 理 器 链 中 相应 方法 ; @ 启 动 异 步 处 理 并 使 用 taskExecutor 提 交 任 务 。 


对 其 中 的 启动 处 理 和 执行 处 理 详细 解释 一 下 ， 启 动 处 理 是 调用 了 startAsyncProcessing 方 法 ， 其 中 做 了 三 件 事 : @ 调 用 clearConcurrentResult 方 法 清空 之 前 并 发 处 理 的 结果 ; @ 调 用 
asyncWebRequest 的 startAsyn<c 方 法 启动 异步 处 理 ; @ 将 processingContext 设 置 给 concurrent-ResultContext 属 性 。startAsyncProcessing 方 法 的 代码 如 下 : 


//org.springframework.web.context .request .asynct .WebAsyncManager 
private void startAsyncProcessing (Object[] processingContext) { 
clearConcurrentResult () 7 
this .concurrentResultContext = processingContext; 
this.asyncWebRequest.startAsync (); 
// 省 略 了 1og 代 码 
} 
Public void clearConcurrentResult () { 
this .concurrentResult = RESULT NONE; 


this .concurrentResultContext = null; 


processingContext 参 数 传 进来 的 是 处 理 器 中 使 用 的 ModelAndViewContainer，concurrent-ResultContext 用 来 在 WebAsyncManager 中 保存 ModelAndViewContainer， 在 请 求 处 理 完成 后 会 设置 
到 RequestMappingHandlerAdapter 中 ， 具 体 过 程 后 面 再 分 析 。 


下 面 再 来 说 一 下 执行 处 理 ， 执 行 处 理 使 用 的 是 taskExecutor， 不 过 需要 注意 的 是 ， 这 里 并 没 直 接 使 用 taskExecutor.submit (callable) 来 提交 ， 而 是 提交 了 新 建 的 Runnable， 并 将 Callable 的 call 方 法 
直接 放 在 run 方 法 里 调用 。 代 码 如 下 : 


//org.springframework.web.context .request .asynct .WebAsyncManager 
this.taskExecutor.submit (new Runnable() { 
@Override 
public void run() { 
Object result = null; 
try { 
interceptorChain.applyPreProcess (asyncWebRequest, callable); 
result = callable.call (); 


}catch (Throwable ex) { 
result = ex; 
}finally { 
result = interceptorChain.applyPostProcess (asyncWebRequest, callable, result); 


} 
setConcurrentResultAndDispatch (result); 


1D); 


这 么 做 主要 有 两 个 作用 : @@ 可 以 在 处 理 过 程 中 的 相应 位 置 调 


不 过 Runnable 是 没有 返回 值 的 ， 所 以 Callable 处 理 的 结果 需要 自己 从 run 方 法 内 部 传递 出 来 ，WebAsyncManager 中 专门 提供 了 一 个 setConcurrentResultAndDispatch 方 法 来 处 理 返 


边 会 将 处 理 的 结果 传递 出 来 ， 代 码 如 下 : 


//org.springframework.web.context .request .asynct .WebAsyncManager 
Private void setConcurrentResultAndDispatch (Object result) { 
synchronized (WebAsyncManager.this) { 
if (hasConcurrentResult()) { 
return; 
} 
this.concurrentResult = result; 
于 
if (this.asyncWebRequest.isAsyncComplete()) { 
logger.error ("Could not complete async processing due to timeout or network error"); 
return; 
} 
if (logger.isDebugEnabled()) { 
logger.debug ("Concurrent result value [" + this.concurrentResult + 
"] - dispatching request to resume processing"); 
} 
this.asyncWebRequest.dispatch (); 


拦截 器 链 中 相应 的 方法 ; @ 在 call 方 法 执行 完 之 前 不 会 像 Future#get(0 那 样 阻塞 线程 。 


的 结果 ， 这 里 


回 


concurrentResult 是 WebAsyncManager 中 用 来 保存 异步 处 理 结果 的 属性 ，hasConcurrent-Result 方 法 用 来 判断 concurrentResult 是 否 已 经 存在 返 | 


回 值 。 整 个 方法 过 程 是 : 如 果 concurrentResult 已 


经 有 返回 值 则 直接 返回 ， 否 则 将 传 入 的 参数 设置 到 concurrentResult， 然 后 调用 asyncWebRequest.isAsyncComplete() 检 查 Request 是 否 已 设置 为 异步 处 理 完成 状态 


处 理 完成 状态 ) ， 如 果 是 则 保存 错误 日 志 并 返回 ， 否 则 调用 asyncWebRequest.dispatch() 发 送 请 求 。Spring MVC 中 异步 请 求 处 理 完成 后 会 再 次 发 起 一 个 相同 的 请 求 ， 
特殊 的 HandlerMethod 来 处 理 它 ， 具 体 过 程 后 面 再 讲解 ， 不 过 通过 Request 的 dispatch 方 法 发 起 的 请 求 使 用 的 还 是 原来 的 Request， 也 就 是 说 原来 保存 在 Request 中 的 


网 络 中 断 会 造成 Request 设 置 为 异步 
然后 在 HandlerAdapter 中 使 用 一 个 


属性 不 会 丢失 。 


startDeferredResultProcessing 方 法 和 startCallableProcessing 方 法 执行 过 程 类 似 ， 只 是 并 没有 使 用 taskExecutor 来 提交 执行 ， 这 是 因为 DeferredResult 并 不 需要 执行 处 理 ， 在 后 面 讲 了 


DeferredResult 的 用 法 后 大 家 就 明白 了 。 


WebAsyncManager 就 分 析 到 这 里 ， 下 面 来 看 WebAsyncUtils。 


WebAsyncUtils 


WebAsyncUtils 里 面 提供 了 四 个 静态 方法 ， 其 中 一 个 是 private 权 限 ， 只 供 内 部 调用 的 ， 也 就 是 一 共 提 供 了 三 个 供 外 部 使 用 的 静态 方法 。 它 们 定义 如 下 : 


// org.springframework.web.context.request.async.WebAsyncUtils; 

public static WebAsyncManager getAsyncManager (ServletRequest servletRequest) 

public static WebAsyncManager getAsyncManager (WebRequest webRequest) 

public static AsyncWebRequest createAsyncWebRequest (HttpServletRequest request, HttpServletResponse response) 


两 个 
有 是 否 有 保存 的 WebAsyncManager 对 象 ， 如 果 有 则 取出 后 直接 返 


由 | 


回 


上 由 


载 的 getAsyncManager 方 法 通过 Request 获 取 WebAsyncManager， 它 们 一 个 使 用 ServletRequest 类 型 的 Redquest， 一 个 使 用 WebRequest 类 型 的 Request， 获 取 过 程 都 是 先 判断 Request 属 性 
， 如 果 没有 则 新 建 一 个 设置 到 Request 的 相应 属性 中 并 返回 ， 下 次 再 获取 时 直接 从 Request 


属性 中 取出 。 


createAsyncWebRequest 方 法 用 于 创建 AsyncWebRequest， 它 使 用 ClassUtils.hasMethod 判 断 传 入 的 Request 是 否 包含 startAsyn<c 方 法 从 而 判断 是 否 支持 异步 处 理 ， 如 果 不 支持 则 新 建 


回 


NoSupportAsyncWebRequest 类 型 的 Request 并 返 | 


22.2.2 Spring MVC 对 异步 请 求 的 支持 


Spring MVC 对 异步 请 求 的 处 理 主要 在 四 个 地 方 进行 支持 ， 详 述 如 下 : 


i 


， 如 果 支 持 则 调用 createStandardServletAsyncWebRequest 方 法 创建 StandardServletAsyncWebRequest 类 型 的 Request 并 返回 。 


FrameworkServlet 中 给 当前 请 求 的 WebAsyncManager 添 加 了 CallableProcessinglnterceptor 类 型 的 拦截 器 RequestBindinglnterceptor， 这 是 定义 在 FrameworkServlet 内 部 的 一 个 私有 的 拦截 


器 ， 其 作用 还 是 跟 FrameworkServlet 处 理 正常 请 求 一 样 ， 在 请 求 处 理 前 将 当前 请 求 的 LocaleContext 和 ServletRequestAttributes 设 置 到 了 LocaleContextHolder 和 RequestContextHolder 中 ， 并 在 请 求 


处 理 完成 后 恢复 ， 添 加 过 程 在 processRequest 方 法 中 ， 相 关 代码 如 下 : 


// org.springframework.web.serVlet.FrameworkServVlet.ProcessReaquest 
WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager (request); 
asyncManager .registerCallableInterceptor (FrameworkServlet .class.getName (), new RequestBindingInterceptor()); 
// org.springframework.web.servlet .FrameworkServlet 
private class RequestBindingInterceptor extends CallableProcessingInterceptorAdapter { 
@Override 
public <T> void preProcess (NativeWebRequest webRequest, Callable<T> task) { 
HttpServletRequest request = webRequest .getNativeRequest (HttpServletRequest.class); 
if (request != null) { 
HttpServletResponse response = webRequest .getNativeRequest (HttpServletResponse.class); 
initContextHolders (request, buildLocaleContext (request), buildRequestAttributes (request, response, null)); 


} 
‘ 
@Override 
public <T> void postProcess (NativeWebRequest webRequest, Callable<T> task, Object concurrentResult) { 


HttpServletRequest request = webRequest .getNativeRequest (HttpServletRequest.class); 
if (request != null) { 
resetContextHolders (request, null, null); 
} 
} 
} 


2) RequestMappingHandlerAdapter 的 invokeHandleMethod 方 法 提供 了 对 异步 请 求 的 核心 支持 ， 其 中 做 了 四 件 跟 异 步 处 理 相关 的 事 


创建 AsyncWebRequest 并 设置 超时 时 间 ， 具 体 时 间 可 以 通过 asyncRequestTimeout 属 性 配置 到 RequestMappingHandlerAdapter 中 。 


l 情 : 


对 当前 请 求 的 WebAsyncManager 设 置 了 四 个 属性 : taskExecutor、asyncWebRequest、callablelnterceptors 和 deferredResultinterceptors， 除 了 asyncWebRequest 的 另外 三 个 都 可 以 在 


RequestMappingHandlerAdapter 中 配置 ，taskExecutor 如 果 没 配置 将 默认 使 用 SimpleAsync-TaskExecutor。 


如 果 当 前 请 求 是 异步 请 求 而 且 已 经 处 理 出 了 结果 ， 则 将 异步 处 理 结果 与 之 前 保存 到 WebAsyncManager 里 的 ModelAndViewContainer 取 出 来 ， 并 将 WebAsyncManager 里 的 结果 清空 ， 然 后 调 | 


ServletlnvocableHandlerMethod 的 wrapConcurrentResult 方 法 创建 Con-currentResultHandlerMethod 类 型 (ServletlnvocableHandlerMethod 的 内 部 类 ) 的 Servletinvocable-HandlerMethod 来 蔡 


进行 解析 并 返回 。 


换 自己 ， 创 建 出 来 的 ConcurrentResultHandlerMethod 并 不 执行 请 求 ， 它 的 主要 功能 是 判断 异步 处 理 的 结果 是 不 是 异常 类 型 ， 如 果 是 则 抛 出 ， 如 果 不 是 则 使 用 ReturnValueHandler 对 


如 果 requestMappingMethod 的 invokeAndHandle 方 法 执行 完 后 检查 到 当前 请 求 已 经 启动 了 异步 处 理 ， 则 会 直接 返回 null。 


RequestMappingHandlerAdapter 中 相关 代码 如 下 : 


//org.springframework.web.servlet .mvce.method.annotation.RequestMappingHandlerAdapter.invokeHandleMethod 
AsyncWebRequest asyncWebRequest = WebAsyncUtils.createAsyncWebRequest (request, response); 
asyncWebRequest .setTimeout (this.asyncRequestTimeout); 
final WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager (request); 
asyncManager .setTaskExecutor (this.taskExecutor); 
asyncManager. setAsyncWebRequest (asyncWebRequest); 
asyncManager .registerCallableInterceptors (this.callableInterceptors); 
asyncManager .registerDeferredResultInterceptors (this.deferredResultInterceptors); 
if (asyncManager.hasConcurrentResult()) { 
Object result = asyncManager.getConcurrentResult (); 
mavContainer= (ModelAndViewContainer)asyncManager .getConcurrentResultContext () [0]; 
asyncManager.clearConcurrentResult (); 
if (logger.isDebugEnabled()) { 
logger.debug ("Found concurrent result value [" + result + "]"); 


// 创建 新 的 处 理 异 步 处 理 结果 的 ServletInvocableHandlerMethod 替 换 掉 原来 的 
requestMappingMethod = requestMappingMethod.wrapConcurrentResult (result); 
} 
requestMappingMethod.invokeAndHandle (webRequest, mavContainer); 
if (asyncManager.isConcurrentHandlingstarted()) { 
return null; 


} 


这 里 的 步骤 3 是 调用 了 ServletlnvocableHandlerMethod 的 wrapConcurrentResult 方 法 创建 了 新 的 ServletlnvocableHandlerMethod 来 处 理 异 步 处 理 的 结果 ， 代 码 如 下 : 


//org.spPringframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod 
ServletInvocableHandlerMethod wrapConcurrentResult (Object result) { 
return new ConcurrentResultHandlerMethod (result, new ConcurrentResultMethodParameter (result)); 


} 


ConcurrentResultHandlerMethod 是 在 ServletiInvocableHandlerMethod 中 定义 的 继承 自 Servlet-InvocableHandlerMethod 的 内 部 类 ， 代 码 如 下 : 


//org.springframework.web.servlet .mvce.method.annotation.ServletInvocableHandlerMethod 
private static final Method CALLABLE METHOD = ClassUtils.getMethod(Callable.class, "call"); 
private class ConcurrentResultHandlerMethod extends ServletInvocableHandlerMethod { 
private final MethodParameter returnType; 
public ConcurrentResultHandlerMethod (final Object result,ConcurrentResultMethodParameter returnType) { 
super (new Callable<Object>() { 
@Override 
public Object call() throws Exception { 
if (result instanceof Exception) { 
throw (Exception) result; 
i 
else if (result instanceof Throwable) { 
throw new NestedServletException ("Async processing failed", (Throwable) result); 
} 
return result; 
} 
}, CALLABLE METHOD); 
setHandlerMethodReturnValueHandlers (ServletInvocableHandlerMethod.this.returnValueHandlers); 
this.returnType = returnType; 
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ConcurrentResultHandlerMethod 调 用 父 类 的 构造 方法 (super) 将 HandlerMethod 中 的 Handler 和 Method 都 蔡 换 掉 了 ，Handler 用 了 新 建 的 匿名 Callable，Method 使 用 了 servlet- 
InvocableHandlerMethod 的 静态 属性 CALLABLE_METHOD， 它 代码 Callable 的 call 方 法 。 新 建 的 Callable 的 执行 逻辑 也 非常 简单 ， 就 是 判断 异步 处 理 的 返回 值 是 不 是 异常 类 型 ， 如 果 是 则 抛 出 异常 ， 不 是 
则 直接 返回 ， 然 后 使 用 和 原来 请 求 一 样 的 返回 值 处 理 器 处 理 返回 值 (因为 在 构造 方法 中 将 原来 ServletlinvocableHandlerMethod 的 返回 值 处 理 器 设置 给 了 自己 ) 。 


回 


3) 返回 值 处 理 器 : 一 共有 四 个 处 理 异 步 请 求 的 返回 值 处 理 器 ， 它 们 分 别 是 AsyncTaskMethodReturnValueHandler、CallableMethodReturnValueHandler、 
DeferredResultMethodReturnValueHandler 和 ListenableFutureReturnValueHandler， 每 一 个 对 应 一 种 类 型 的 返回 值 ， 它 们 的 作用 主要 是 使 用 WebAsyncManager 启 动 异 步 处 理 ， 后 面 依次 对 每 一 类 返 


回 值 进行 分 析 。 


Bll 
回 


4) 在 DispatcherServlet 的 doDispatch 方 法 中 ， 当 HandlerAdapter 使 用 Handler 处 理 完 请 求 时 ， 会 检查 是 否 已 经 启动 了 异步 处 理 ， 如 果 启 动 了 则 不 再 往 下 处 理 ， 直 接 返 回 ， 相 关 代 码 如 下 : 


// org.springframework.web.servlet .DispatcherServlet .doDispatch 
mv = ha.handle (processedRequest, response, mappedHandler.getHandler ()); 
if (asyncManager.isConcurrentHandlingSstarted()) { 

return; 


} 


检查 方法 是 调用 的 WebAsyncManager 的 isConcurrentHandlingStarted 方 法 ， 其 实 内 部 就 是 调用 的 request 的 isAsyncStarted 方 法 ， 代 码 如 下 : 


//org.spPringframework.web.context.request.asynct.WebAsyncManageT 
public boolean isConcurrentHandlingStarted() { 
return ((this.asyncWebRequest != null) && this.asyncWebRequest.isAsyncStarted()); 


} 


Spring MVC 中 跟 异步 请 求 处 理 相关 的 四 个 位 置 就 分 析 完 了 。 主 要 处 理 流程 是 这 样 的 : 首先 在 处 理 器 中 返回 需要 启动 异步 处 理 的 类 型 时 (四 种 类 型 ) 相应 返回 值 处 理 器 会 调用 WebAsyncManager 的 相 
关 方 法 启动 异步 处 理 ， 然 后 在 DispatcherServlet 中 将 原来 请 求 直 接 返回 ， 当 异步 处 理 完成 后 会 重新 发 出 一 个 相同 的 请 求 ， 这 时 在 RequestMappingHandlerAdapter 中 会 使 用 特殊 的 
ServletinvocableHandlerMethod 来 处 理 请 求 ， 处 理 方法 是 : 如 果 异 步 处 理 返 回 的 结果 是 异常 类 型 则 抛 出 异常 ， 否 则 直接 返回 异步 处 理 结果 ， 然 后 使 用 返回 值 处 理 器 处 理 ， 接 着 返回 DispatcherServlet 中 按 
正常 流程 往 下 处 理 。 


回 


lf 步 处 理 完成 后 会 重新 发 起 一 个 请 求 ， 这 时 会 重新 查找 HandlerMethod 并 初始 化 PathVariable、MatrixVariable 等 参数 ， 重 新 初始 化 Model 中 的 数据 并 再 次 执行 Handler-Interceptor 中 相应 的 方法 。 
这 么 做 主要 是 可 以 复 用 原来 的 那 套 组 件 进行 处 理 而 不 需要 重新 定义 。 不 过 新 请 求 的 HandlerMethod 是 用 的 专门 的 类 型 ， 而 Model 是 使 用 的 原来 保存 在 WebAsyncManager 的 concurrentResultContext 属 
性 中 的 ModelAndViewContainer 所 保存 的 Model， 所 以 这 里 的 查找 HandlerMethod 和 初始 化 Model 的 过 程 是 没 用 的 ， 在 这 里 可 以 进行 一 些 优化 ， 比 如 ， 将 创建 ConcurrentResultHandlerMethod 的 过 程 
放 在 HandlerMapping 中 (这 样 也 更 符合 组 件 的 功能 ) ， 然 后 在 调用 ModelFactory 的 initModelI 方 法 前 判断 是 不 是 异步 处 理 dispatcher 过 来 的 请 求 ， 如 果 是 则 不 再 初始 化 了 ， 或 者 干脆 创建 新 的 
HandlerAdapter 来 处 理 。 


除了 上 述 可 以 优化 的 地 方 ， 这 里 还 有 两 个 漏洞 ， 第 一 个 是 相应 的 拦截 器 里 的 方法 会 被 调用 两 次 ， 这 是 不 合适 的 ， 而 且 有 的 时 候 还 会 出 问题 ， 比 如 ， 如 果 用 了 拦截 器 来 检查 Token ， 那 么 第 一 次 检查 通过 
后 就 会 将 相应 内 容 删 除 ， 第 二 次 再 检查 的 时 候 就 检查 失败 了 ， 这 就 有 问题 了 。 第 二 个 是 通过 FlashMap 传 递 Redirect 参 数 的 情况 ， 在 前 面 分 析 FlashMapManager 获 取 FlashMap 的 时 候 说 过 ， 每 次 获取 后 就 
会 将 相应 的 FlashMap 删 除 ， 但 异步 请 求 会 获取 两 次 ， 如 果 异 步 处 理 器 是 Redirect 到 的 结果 处 理 器 ， 并 且 使 用 FlashMap 传 递 了 参数 ， 这 种 情况 下 如 果 在 第 二 次 获取 FlashMap 的 时 候 (异步 请 求 处 理 完了 ) 


正好 用 户 又 发 了 一 个 相同 的 请 求 ， 而 且 RedirectView 已 经 将 FlashMap 设 置 到 了 session， 在 获取 之 前 可 能 被 前 面 的 请 求 获取 删除 ， 导 致 自 己 获取 不 到 ， 这 么 说 不 容易 理解 ， 下 面 将 两 个 请 求 的 处 理 过 程 列 出 


来 大 家 就 容易 理解 了 : 
请 求 1 

saveOutputFlashMap 
retrieveAndUpdate 
saveOutputFlashMap 
retrieveAndUpdate 
retrieveAndUpdate 
retrieveAndUpdate 


这 样 请 求 2 设置 的 FlashMap 就 会 被 请 求 1 的 第 二 次 retrieveAndUpdate 获 取 到 并 从 Session 中 删除 ， 请 求 2 就 获取 不 到 了 ， 这 样 两 个 请 求 的 值 就 都 出 了 问题 了 。 


这 里 的 第 二 个 漏洞 只 是 从 原理 上 来 说 存在 ， 一 般 不 会 造成 什么 影响 ， 


己 处 理 一 下 。 


异步 处 理 流程 就 说 到 这 里 ， 下 面 分 析 每 一 类 返回 值 的 具体 处 理 过程 。 


22.2.3 WebAsyncTask 和 Callable 类 型 异步 请 求 的 处 理 过 程 及 用 法 


当 处 理 器 方法 返回 WebAsyncTask 或 Callable 类 型 时 将 自动 
ReturnValue 方 法 如 下 : 


因为 这 种 情况 发 生 的 概率 非常 小 ， 但 第 一 个 漏洞 是 比较 严重 的 ， 如 果真 正 使 


了 类 似 判断 Token 等 的 拦截 器 需要 在 : 


体 方法 内 部 自 


异步 处 理 。 下 面 来 看 一 下 处 理 WebAsyncTask 类 型 返回 值 的 处 理 器 AsyncTaskMethodReturnValueHandler， 它 的 handle- 


//org.springframework.web.servlet .mve.method.annotation.AsyncTaskMethodReturnValueHandler 
public void handleReturnValue (Object returnValue, MethodParameter returnType, 
ModelAndViewContainer mavContainer, NativeWebRequest webRequest) throws Exception { 


if (returnValue == null) { 
mavContainer.setRequestHandled (true); 
return; 
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WebAsyncTask<?> webAsyncTask = (WebAsyncTask<?>) returnValue; 


webAsyncTask.setBeanFactory (this.beanFactory); 


WebAsyncUtils.getAsyncManager (webRequest) .startCallableProcessing (webAsyncTask, mavContainer); 


如 果 返 回 值 为 null， 就 会 给 mavContainer 设 置 为 请 求 已 处 理 ， 然 后 返回 。 如 果 返 回 值 不 为 null， 调 有 


WebAsyncManager 的 startCallableProcessing 方 法 处 理 请 求 。WebAsyncManager 是 使 


WebAsyncUtils 获 取 的 。 下 面 来 看 一 个 例子 ， 首 先 给 配置 Spring MVC 的 Servlet 添 加 异步 处 理 支 持 ， 也 就 是 添加 async-supported 属 性 ， 代 码 如 下 : 


<!-- web.xml 
<servlet> 
<servlet-name>let'sGo</servlet-name> 


--> 


<servlet-class>org.springframework.web.servlet .DispatcherServlet</servlet-class> 


<init-param> 
<param-name>contextConfigLocation</param-name> 


<param-value>WEB-INF/let'sGo-servlet .xml</param-value> 


</init-param> 
<async-supported>true</async-supported> 
</servlet> 


接 下 来 写 一 个 AsyncController， 代 码 如 下 : 


package com.excelib.controller; 

// 省 略 了 imports 

Q@Controller 

public class AsyncController { 
@ResponseBody 
@RequestMapping (value = "/webasynctask",produces 
public WebAsyncTask<String> webAsyncTask(){ 


= "text/plain; charset=UTF-8") 


System.out .println ("WebAsyncTask 处 理 器 主线 程 进入 "); 
WebAsyncTask<String> task = new WebAsyncTask<String> (new Callable <String>() { 


QOverride 
public String call() throws Exception { 
Thread. sleep (5*1000L); 


System.out .println ("WebAsyncTask 处 理 执行 中 …"); 


return " 久 等 了 "; 
} 
1); 


System.out .println ("WebAsyncTask 处 理 器 主线 程 退 出 "); 


return task; 


这 里 新 建 了 WebAsyncTask， 并 使 
直接 返回 给 浏览 器 。 当 调 


的 Callable 处 理 。 


匿名 类 建 了 Callable 进 行 异步 处 理 ， 实 际 使 
“http://localhost:8080/webasynctask” 时 ,会 在 等 待 大 约 5 秒 后 返回 给 浏览 器 “ 久 等 了 ”三 个 字 。 


现在 再 返回 去 看 WebAsyncManager 的 startCallableProcessing 方 法 就 容易 理解 了 ， 其 实 就 是 先 添加 拦截 器 ， 并 在 相应 的 地 方 执行 拦截 器 里 的 方法 ， 最 后 使 


当然 这 里 只 是 给 WebAsyncTask 设 置 了 Callable， 除 此 之 外 还 可 以 设置 executor、timeout、timeoutCallback 和 completionCallback 等 属性 。 


Callable 的 处 理 其 实 是 在 WebAsyncManager 内 部 封装 成 WebAsyncTask 后 再 处 理 的 。 当 处 理 器 中 返回 Callable 类 型 的 返回 


回 值 ， 它 的 handleReturnValue 方 法 代码 如 下 : 


中 可 以 在 其 中 写 数 据 库 请 求 等 耗 时 的 业务 ， 这 里 直接 等 了 5 秒 来 模拟 。 处 理 器 注释 了 @Response-Body， 其 返回 值 会 


值 时 ，Spring MVC 会 使 


taskExecutor 调 


返回 WebAsyncTask 中 


CallableMethodReturnValueHandler 来 处 理 返 


//org.springframework.web.servlet .mvc.method.annotation.CallableMethodReturnValue Handler 
Public void handleReturnValue (Object returnValue, MethodParameter returnType, 
ModelAndViewContainer mavContainer, NativeWebRequest webRequest) throws Exception { 


if (returnValue == null) { 
mavContainer.setRequestHandled (true); 
return; 


. 


Callable<?> callable = (Callable<?>) returnValue; 
WebAsyncUtils.getAsyncManager (webRequest) .startCallableProcessing (callable, mavContainer); 


bE: 


这 里 直接 调用 了 WebAsyncManager 的 startCallableProcessing 方 法 进行 处 理 ， 不 过 这 是 一 个 


载 的 第 一 个 参数 是 Callable 类 型 的 startCallableProcessing 方 法 ， 


其 代码 如 下 : 


//org.springframework.web.context .request .asynct .WebAsyncManager 


public void startCallableProcessing (Callable<?> callable, Objecthttp://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/15447/0EBPS/Text/... 


Assert .notNull (callable, "Callable must not be null"); 
startCallableProcessing (new WebAsyncTask (callable), processingContext); 


proc 


它 还 是 将 Callable 封 装 成 了 WebAsyncTask 然 后 处 理 的 。 如 果 WebAsyncTask 中 只 有 Callable 而 没有 别 的 属性 的 时 候 可 以 直接 返回 


package com.excelib.controller; 
// 省 略 了 imports 
public class AsyncController { 
@ResponseBody 
Q@RequestMapping (value = "/callable",produces = "text/plain; charset=UTF-8") 
public Callable<String> callable(){ 
System.out .println("Callable 处 理 器 主线 程 进入 ")，; 
Callable<String> callable = new Callable<string>() { 
QOverride 
Public String call() throws Exception { 
Thread.sleep(5 * 1000L); 
System.out .println ("Callable 处 理 执 行 中 …"); 
return " 久 等 了 "; 
i 
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System.out .Println("Callable 处 理 器 主线 程 退 出 ") ; 
return callable; 


Callable， 比 如 前 面 的 处 理 器 可 以 修改 为 : 


它 和 前 面 使 用 WebAsyncTask 执 行 的 效果 是 一 样 的 。 


22.2.4 DeferredResult 类 型 异步 请 求 的 处 理 过 程 及 用 法 


DeferredResult 是 spring 提 供 的 一 种 用 于 保存 延迟 处 理 结 果 的 类 ， 当 一 个 处 理 器 返回 DeferredResult 类 型 的 返回 值 时 将 启动 异步 处 理 。 


不 过 DeferredResult 和 WebAsyncTask 的 使 用 方法 完全 不 同 ，DeferredResult 并 不 是 用 于 处 理 请 求 的 ， 而 且 也 不 包含 请 求 的 处 理 过 程 ， 它 是 用 来 封装 处 理 结果 的 


样 。 


使 用 DeferredResult 的 难点 就 在 理解 其 含义 ， 对 其 含义 理解 了 之 后 就 会 觉得 非常 简单 ， 而 且 使 用 起 来 也 很 方便 。 在 返回 WebAsyncTask 时 是 


， 有 点 像 Java 中 的 Future， 但 不 完全 一 


因为 处 理 的 时 间 过 长 所 以 使 用 了 异步 处 理 ， 但 其 实 还 是 自己 


来 处 理 的 (因为 WebAsyncTask 需 要 提供 Callable) ， 而 返回 DeferredResult 表 示 要 将 处 理 交 个 别人 了 ， 什 么 时 候 处 理 完 、 怎 么 处 理 的 自己 并 不 需要 知道 ， 这 就 好 像 在 单位 经 常用 到 的 “ 受 否 ， 请 批示 ”的 
请 示 报告 ， 自 己 并 不 知道 什么 时 候 能 批 下 来 ， 而 且 也 不 需要 知道 具体 批示 过 程 ， 只 需要 知道 最 后 的 结果 就 可 以 了 。DeferredResult 就 是 来 保存 结果 的 ， 当 处 理 完 之 后 调用 它 的 setResult 方 法 将 结果 设置 给 它 


就 可 以 了 。 


DeferredResult 还 提供 了 一 些 别 的 属性 ， 如 resultHandler 可 以 在 设置 了 结果 之 后 对 结果 进行 处 理 、timeout 设 置 超时 时 间 、timeoutCallback 设 置 超时 处 理 方法 、completionCallback 设 置 处 理 完成 后 


的 处 理 方法 、timeoutResult 设 置 超时 后 返回 的 结果 等 。 


下 面 看 一 下 Spring MVC 中 处 理 DeferredResult 返 回 值 的 DeferredResultMethodReturnValueHandler 处 理 器 ， 它 的 handleReturnValue 方 法 如 下 : 


//org.springframework.web.servlet .mvc.method.annotation.DeferredResultMethodReturnValueHandler 
public void handleReturnValue (Object returnValue, MethodParameter returnType, 
ModelAndViewContainer mavContainer, NativeWebRequest webRequest) throws Exception { 


if (returnValue == null) { 
mavContainer.setRequestHandled (true); 
return; 

} 

DeferredResult<?> deferredResult = (DeferredResult<?>) returnValue; 


WebAsyncUtils.getAsyncManager (webRequest) .startDeferredResultProcessing (deferredResult, mavContainer); 
} 


这 里 直接 调用 了 WebAsyncManager 的 startDeferredResultProcessing 方 法 进行 处 理 。 


下 面 来 看 一 个 返回 值 为 DeferredResult 的 处 理 器 的 例子 。 


Package com.excelib.controller; 
// 省 略 了 imports 
Q@Controller 
public class AsyncController { 
@ResponseBody 
Q@RequestMapping (value = "/deferred",produces = "text/plain; charset=UTF-8") 
public DeferredResult<String> deferredResultExam() { 
final DeferredResult<String> result = new DeferredResult<String>(7*1000L，" 超 时 了 "); 
approve (result); 
return result; 
} 
Private void approve (DeferredResult<String> result){ 
Runnable r = new Runnable() { 
QOverride 
public void run() { 
try { 
Thread.sleep(5 * 1000L); 
result .setResult ("同意 "+new SimpleDateFormat ("yyyy-MM-dd") .format (new Date())); 
} catch (Exception e) { 
e.printstackTrace (); 
} 
i 
i 


new Thread (z) .start (); 


在 处 理 器 方法 中 直接 新 建 了 个 DeferredResult 类 型 的 result 代 表 处 理 结果 ， 构 造 方法 的 两 个 参数 分 别 表示 超时 时 间 和 超时 后 返回 的 结果 ， 建 出 来 后 将 其 交 给 approve 方 法 进行 处 理 (审批 ) ， 当 approve 


方法 给 result 使 用 setResult 方 法 设置 了 值 后 异步 处 理 就 完成 了 。 


加 


approve 方 法 启动 了 一 个 新 线程 ， 然 后 在 里 面 等 待 5 秒 后 给 result 设 置 值 。 
“http:Wlocalhost:8080/deferred” 时 ， 浏 览 器 会 在 过 大 约 5 秒 后 显示 “同意 2015-04-02” 。 


现在 大 家 再 返回 去 看 WebAsyncManager 的 startDeferredResultProcessing 方 法 就 容易 理解 了 ， 它 并 没有 而 且 也 不 需要 执行 ， 只 需 


为 这 里 的 处 理 器 有 @ResponseBody 注 释 ， 所 以 返回 值 会 直接 显示 到 浏览 器 ， 当 调 


等 待 别 的 线程 给 设置 返回 


值 就 可 以 了 。 方 法 中 给 result 设 置 了 处 理 


当 有 返回 值 返回 时 会 自动 调 


返回 值 的 处 理 器 ， 


， 代 码 如 下 : 


//org.springframework.web.context .request .asynct .WebAsyncManager.startDeferredResultProcessing 
deferredResult .setResultHandler (new DeferredResultHandler() { 


1D); 


这 里 的 处 理 器 中 首先 调 


现在 大 家 应 该 对 DeferredResult 返 回 
处 理 的 它 并 不 关心 ， 


QOverride 


public void handleResult (Object result) { 


result = 


setConcurrentResultAndDispatch (result); 


} 


了 拦截 器 链 中 的 applyPostProcess 方 法 ， 然 后 调 有 


22.2.5 ”ListenableFuture 类 型 异步 请 求 的 处 理 过 程 及 用 法 


ListenableFuture 继 承 自 Future，Future 在 前 面 已 经 介绍 过 了 


Future 基 础 上 增加 了 可 以 添加 处 理 成 功 和 处 理 失败 回调 方法 的 方法 ， 代 码 如 下 : 


值 的 异步 处 理 就 理解 了 ，DeferredResult 是 一 个 
也 就 给 我 们 带 来 了 很 大 的 自由 。 


interceptorChain.applyPostProcess (asyncWebRequest, deferredResult, result); 


其 


于 保存 返回 值 的 类 ， 只 需要 在 业务 处 理 完成 后 调 


setResult 方 法 设置 结果 就 可 以 了 ， 


setConcurrent-ResultAndDispatch 方 法 处 理 了 返回 值 ，setConcurrentResultAndDispatch 方 法 前 面 已 经 说 过 


至 于 怎么 处 理 的 、 在 哪里 


， 它 用 来 保存 Callable 的 处 理 结果 ， 它 提供 了 get 方 法 来 获取 返回 值 ， 不 过 Future 并 不 会 在 处 理 完成 后 主动 提示 。ListenableFuture 在 


package org.springframework.util.concurrent; 

import java.util.concurrent.Future; 

public interface ListenableFuture<T> extends Future<T> { 

void addCcallback (ListenableFutureCallback<? super T> callback); 
void addCcallback (SuccessCallback<? super T> successCallback, FailureCallback failureCallback); 


ListenableFutureCallback 继 承 自 SuccessCallback 和 FailureCallback 接 [ 


后 两 个 接口 分 别 


DeferredResult 中 的 resultHandler 差 不 多 ， 它 们 定义 如 下 : 


有 一 个 onSuccess 方 法 和 onFailure 方 法 ， 


于 处 理 异步 


上 5 处理 成 功 的 返回 值 和 异步 处 理 失 败 的 返回 值 ， 就 和 


package org.springframework.util.concurrent; 
public interface ListenableFutureCallback<T> extends SuccessCallback<T>, FailureCallback { 


i 


Package org.springframework.util.concurrent; 
public interface SuccessCallback<T> { 
void onSuccess (T result); 


} 


Package org.springframework.util.concurrent; 
public interface FailureCallback { 
void onFailure (Throwable ex); 


等 


} 


ListenableFuture 是 spring4.0 新 增 的 接 
都 有 不 同 的 方法 ， 而 且 还 


， 它 主要 使 用 在 需要 调 | 


可 以 使 


ListenableFuture<ResponseEntity<String>> futureEntity = template.getForEntity ( 
"http://localhost:8080/students/{studentId} /books/ {bookId}", String.class, "176","7"); 


别 的 服务 的 时 候 ，spring 还 同时 提供 了 AsyncRestTemplate， 用 它 可 以 方便 地 发 起 各 种 Http 请 求 ， 不 同类 型 的 请 求 (如 Get、Post 
url 的 模板 参数 uriVariables (类 似 于 处 理 器 参数 中 的 pathVariables) ， 它 的 返回 值 就 是 ListenableFuture 类 型 ， 比 如 ， 


可 以 这 样 使 


这 样 就 可 以 返回 http:Wlocalhost:8080/students/176/books/7 的 Get 请 求 结果 ， 而 且 是 非 阻塞 的 异步 调用 。 


下 面 看 一 下 处 理 ListenableFuture 返 回 值 的 处 理 器 ListenableFutureReturnValueHandler， 


它 的 handleReturnValue 方 法 代码 如 下 : 


//org.springframework.web.servlet .mvce.method.annotation.ListenableFutureReturnValueHandler 
public void handleReturnValue (Object returnValue, MethodParameter returnType, 
ModelAndViewContainer mavContainer, NativeWebRequest webRequest) throws Exception { 


if 


(returnValue == null) { 


mavContainer.setRequestHandled (true); 


return; 


‘ 


final DeferredResult<Object> deferredResult = 


new DeferredResult<Object>(); 


WebAsyncUtils.getAsyncManager (webRequest) .startDeferredResultProcessing (deferredResult, mavContainer); 


ListenableFuture<?> future = 


(ListenableFuture<?>) returnValue; 


future.addCallback (new ListenableFutureCallback<Object>() { 


Q@Override 


public void onSuccess (Object result) { 
deferredResult .setResult (result); 


} 
QOverride 


public void onFailure (Throwable ex) { 
deferredResult .setErrorResult (ex); 


方法 进 


种 特殊 使 


可 以 看 到 在 ListenableFuture 的 返回 值 处 理 器 旦 
行 处 理 ， 然 后 给 ListenableFuture 类 型 的 返回 值 添加 了 回调 方法 ， 在 回调 
方式 。 大 家 好 好 体会 这 


实际 使 用 了 DeferredResult， 首 先 新 建 了 DeferredResult 类 型 的 deferredResult， 接 着 调 
方法 中 对 deferredResult 设 置 了 返 | 


值 。 


回 


里 的 处 理 过 程 就 可 以 对 “DeferredResult 跟 


下 面 来 看 一 个 ListenableFuture 类 型 返回 值 处 理 器 的 例子 。 


Package com.excelib.controller; 
// 省 略 了 imports 
@Controller 

public class AsyncController { 


@RequestMapping (value = 


"/listenable",produces = 


public ListenableFuture<ResponseEntity<String>> listenableFuture() { 


ListenableFuture<ResponseEntity<String>>future = 


"http://localhost:8080/index", String.class); 


return future; 


体 处 理 过 程 无 关 ” 这 


一 点 理解 得 更 加 深入 


"text/plain; charset=UTF-8") 


new AsyncRestTemplate() .getForEntity( 


了 WebAsyncManager 的 startDeferred-ResultProcessing 
可 以 说 ListenableFuture 类 型 的 返回 值 只 是 DeferredResult 类 型 返回 值 处 理 器 的 一 


器 会 显示 “excelib Go Go Go!” 


多 知道 点 


这 里 处 理 器 的 返回 值 ListenableFuture 的 泛 型 是 ResponseEntity 类 型 ， 所 以 不 需要 使 
， 也 就 是 “http://localhost:8080/index” 的 返回 


结果 。 


@ResponseBody 注 释 也 会 将 返回 值 直接 显示 到 ) 浏 览 器 


ListenableFuture 和 Future 的 比较 


。 当 调 


“http://localhost:8080/listenable” 时 ,浏览 


ListenableFuture 在 Future 的 基础 上 增加 了 可 以 添加 处 理 成 功 和 处 理 失败 回调 方法 的 方法 ， 这 就 从 Future 的 “ 拉 ” 模 式 变 成 了 ListenableFuture 的 “ 推 ” 模 式 。 


Future 只 能 调用 get 方 法 来 主动 拉 数 据 ， 而 且 get 方 法 还 是 阻塞 的 ， 而 Listenable-Future 可 以 等 待 处 理 完 成 后 自己 将 结果 推 过 来 ， 而 且 不 会 阻塞 线程 ， 这 么 看 好 像 ListenableFuture 比 Future 更 好 用 。 其 实在 很 多 
地 方 Future 中 阻塞 的 get 方 法 才 是 真正 需要 的 ， 因 为 很 多 时 候 都 需要 等 到 线程 处 理 的 结果 才 可 以 向 下 进行 ， 比 如 ， 要 找 四 个 数 中 最 大 的 那个 ， 可 以 将 四 个 数 分 成 两 组 然后 启动 两 个 线程 分 别 选 出 每 组 中 比较 大 
的 数 ， 然 后 再 启动 一 个 线程 取出 两 个 结果 中 比较 大 的 ， 那 就 是 四 个 数 中 最 大 的 数 ， 代 码 如 下 : 


public class ObtainBigger { 

public static void main (String[] args) throws ExecutionException, InterruptedException { 
ExecutorService executor = Executors .newCachedThreadPool () 7 
// 需要 查找 最 大 数 的 数组 
Double data[] = new Double[]{210.32, 517.96, 986.77, 325.13}; 
// 获取 前 两 个 里 较 大 的 
BiggerCallable cl = new BiggerCallable (data[0],data[1]); 
Future<Double> biggerl = executor.submit (c1); 
// 获取 后 两 个 里 较 大 的 
BiggerCallable c2 = new BiggerCallable (data[2],data[3]); 
Future<Double> bigger2 = executor.submit (c2); 
// 获取 两 个 结果 中 较 大 的 ， 这 时 会 阻塞 ， 只 有 前 面 两 个 结果 都 返回 时 才 会 往 下 进行 
BiggerCallable c = new BiggerCallable (biggerl .get (),bigger2.get ()); 
Future<Double> bigger = executor.submit (c); 
// 输出 结果 
System.out .println (bigger.get ()); 
executor.shutdown (); 

} 

private static class BiggerCallable implements Callable { 
Double dl, d2; 
public BiggerCallable (Double dl, Double d2){ 


this.dl = dl; 
this.d2 = d2; 
} 
QOverride 


Public Object call() throws Exception { 
return dl1>d2?d1:d27 
} 


这 里 使 用 了 内 部 类 BiggerCallable 来 比较 ， 第 三 个 BiggerCallable 创 建 时 前 两 个 c1) c2 必 须 已 经 执行 完 才 可 以 ， 否 则 就 会 出 问题 ， 所 以 在 这 种 情况 下 阻塞 就 是 必要 的 ， 而 且 这 种 需要 线程 返回 结果 后 才能 往 下 
进行 的 情况 很 多 。 而 ListenableFutute 的 典型 用 法 就 是 Web 异 步 请 求 这 种 并 不 需要 对 线程 返回 的 结果 进一步 处 理 ， 而 且 线 程 在 返回 之 前 主线 程 可 以 继续 往 下 走 的 情况 ， 这 时 如 果 程 序 阻塞 就 起 不 到 应 有 的 作用 
了 。 


22.3 ”小结 


本 章 系统 地 介绍 了 Servlet 和 Spring MVC 中 异步 处 理 的 原理 和 使 用 方法 ， 首 先 介绍 了 Servlet3.0 中 对 异步 请 求 的 支持 及 其 使 用 方法 ， 然 后 又 分 析 了 Spring MVC 中 异步 处 理 的 执行 过 程 并 编写 了 示例 程 


序 。 


Servlet 中 使 用 异步 请 求 非常 方便 ， 只 需要 调用 request 的 startAsync 方 法 ， 然 后 对 其 返回 值 AsyncContext 进 行 处 理 ， 如 果 需 要 还 可 以 为 其 添加 AsyncListener 监 听 器 ， 它 可 以 监听 异步 请 求 的 启动 、 超 
时 、 处 理 完成 和 处 理 异 常 四 个 节点 。 


Spring MVC 为 异步 请 求 提供 了 专门 的 工具 ， 并 对 处 理 器 默认 提供 了 四 种 用 于 异步 处 理 的 返回 值 : Callable、WebAsyncTask、DeferredResult 和 ListenableFuture。 对 异步 请 求 的 支持 主要 在 
RequestMappingHandlerAdapter 中 ， 启 动 异步 处 理 在 各 返回 值 对 应 的 返回 值 处 理 器 中 。 


